From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 6 08:40:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB00016A4CE for ; Sun, 6 Mar 2005 08:40:50 +0000 (GMT) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76A1F43D53 for ; Sun, 6 Mar 2005 08:40:50 +0000 (GMT) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.1/8.13.1) with ESMTP id j268eiSa004556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 00:40:44 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.1/8.13.1/Submit) id j268eiPT004555; Sun, 6 Mar 2005 00:40:44 -0800 (PST) (envelope-from steve) Message-Id: <200503060840.j268eiPT004555@wattres.watt.com> X-Newsgroups: local.freebsd-hackers In-Reply-To: <20050304032003.89305.qmail@web52702.mail.yahoo.com> Organization: Watt Consultants From: steve@Watt.COM (Steve Watt) Date: Sun, 6 Mar 2005 00:40:44 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: kamalp@acm.org X-Archived: 1110098444.794883152@wattres.Watt.COM X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on wattres.Watt.COM X-Virus-Status: Clean cc: hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 08:40:51 -0000 [ Attempted to clean up citations, apologies if I mis-attribute something ] In article <20050304032003.89305.qmail@web52702.mail.yahoo.com>, Kamal R. Prasad wrote: Kamal>--- Julian Elischer wrote: Julian> Kamal R. Prasad wrote: Kamal>>--- Julian Elischer wrote: Julian>>Kamal R. Prasad wrote: Kamal>>>Maybe the freebsd implementation should implement Kamal>>>NPTL in entirety. Julian>>NPTL? Julian>>New Pthreads Library from Library? No, Native POSIX Threads Library for Linux. It's a Linux implementation of kernel-level threads that was spearheded by Ulrich Drepper. It fixes most (all?) of the ugly signal problems that LinuxThreads had. Kamal>>Yes. Julian>>isn't that GPL'd? Yes. Kamal>No -it is a standard. The linux implementation of nptl Kamal>is gpl'ed. No, POSIX 1003.1 is the standard, the thread portion was known for some time as 1003.1c, but was combined in with the base. NPTL is a particular (less brain damaged than LinuxThreads) implementation of the POSIX thread standard. Likewise, scheduler activations are a decent implementation of threads. I'll refrain from commenting further about libc_r. Julian> so how does that differ from what we have ... a Julian> native pthreads library? Kamal>I just said if it was conformant with NPTL, thread and Kamal>process scheduling would co-exist. Uh, as far as I understand, in NPTL, each thread gets a scheduler slot, and it is my understanding that there is nothing to protect against the issue that Julian is asking about (1000 threads of a single process *do* get 1000 times the time slices). Whether that is a bug or a feature depends very heavily on the system load. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 6 10:14:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 976C616A4CE for ; Sun, 6 Mar 2005 10:14:24 +0000 (GMT) Received: from web52702.mail.yahoo.com (web52702.mail.yahoo.com [206.190.39.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 263C443D48 for ; Sun, 6 Mar 2005 10:14:24 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 44747 invoked by uid 60001); 6 Mar 2005 10:14:23 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=r5Qq3/doae9T8gL7cE/mND3GgXUFx3bMZppmaiAcGtndSF4ivwNqGmcpBPjr2J0zUAOoQnXWTvARq5CSO6GY3hBQ8x9Td+Qeddz1pJWUAqA6G13Wrp4rk7nPDHgvzVQdUwuVh7pEwjloc8WPjkv6R5q4BePCzyG4J/CVJFf9w8o= ; Message-ID: <20050306101423.44745.qmail@web52702.mail.yahoo.com> Received: from [202.91.78.244] by web52702.mail.yahoo.com via HTTP; Sun, 06 Mar 2005 02:14:23 PST Date: Sun, 6 Mar 2005 02:14:23 -0800 (PST) From: "Kamal R. Prasad" To: Steve Watt In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 10:14:24 -0000 --- Steve Watt wrote: [snip] > > No, POSIX 1003.1 is the standard, the thread portion > was known for > some time as 1003.1c, but was combined in with the > base. > Ok -I meant the POSIX std when I answered Julian. > NPTL is a particular (less brain damaged than > LinuxThreads) > implementation of the POSIX thread standard. > > Likewise, scheduler activations are a decent > implementation of doesn't that have a problem with M:N performance (M |= N)? > threads. I'll refrain from commenting further about > libc_r. > > Julian> so how does that differ from what we have > ... a > Julian> native pthreads library? > > Kamal>I just said if it was conformant with NPTL, > thread and > Kamal>process scheduling would co-exist. > > Uh, as far as I understand, in NPTL, each thread > gets a scheduler > slot, and it is my understanding that there is > nothing to protect > against the issue that Julian is asking about (1000 > threads of a > single process *do* get 1000 times the time slices). > (AFAIK) Referring to the POSIX std (and not NPTL) -if threads were defined within process scope and not system scope -the scheduling attributes of the process will apply. regards -kamal ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 6 11:24:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F94816A4CE for ; Sun, 6 Mar 2005 11:24:24 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C65D43D46 for ; Sun, 6 Mar 2005 11:24:23 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j26BOElR003175; Sun, 6 Mar 2005 12:24:15 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Charles M. Hannum" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 05 Mar 2005 21:06:04 GMT." <200503052106.05001.abuse@spamalicious.com> Date: Sun, 06 Mar 2005 12:24:14 +0100 Message-ID: <3174.1110108254@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: elric@imrryr.org cc: briggs@netbsd.org cc: perry@piermont.com cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 11:24:24 -0000 In message <200503052106.05001.abuse@spamalicious.com>, "Charles M. Hannum" wri tes: >While you might claim that the dedication to study the user's behavior and >mount such an attack is fanciful, I claim that it is not. Under observation, >GBDE's additional techniques do not stand up to the claim of being "spook >strength". GBDE only makes that claim for a "cold disk" for pretty much the very reasons you mention. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 6 11:52:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8879116A4CE for ; Sun, 6 Mar 2005 11:52:06 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id A102D43D1D for ; Sun, 6 Mar 2005 11:52:05 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j26Bpk7r003368; Sun, 6 Mar 2005 12:51:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Steven M. Bellovin" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 05 Mar 2005 11:19:32 EST." <20050305161932.8A9743BFF12@berkshire.machshav.com> Date: Sun, 06 Mar 2005 12:51:46 +0100 Message-ID: <3367.1110109906@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: elric@imrryr.org cc: abuse@spamalicious.com cc: briggs@NetBSD.org cc: perry@piermont.com cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 11:52:06 -0000 In message <20050305161932.8A9743BFF12@berkshire.machshav.com>, "Steven M. Bell ovin" writes: >etc. I think we need to be careful about phrases like "one can". I >decided to stop supposing and gather some real data, so I wrote some >analysis tools to measure the entropy of disk drives. I need to >rewrite some of my tools and do a lot more analysis, but I think the >results thus far are quite interesting. See >http://www.cs.columbia.edu/~smb/rawdisk-entropy.ps I did something similar when I studied if more intricate sector placement hiding algorithms would be worthwhile. In addition to various UNIX disks I also analyzed disk images from windows server, windows laptop, s390/MVS volumes, archive disk images from an official government library and optical disk images from an archive of scanned documents. Overall, almost all the disks except the archive and mainframe disks had a "zero peak" with sectors never written to. The rest of the curve can have any shape you can imagine but will often have some number of distinct peaks for certain content types. The highest entropy I found was a disk-images from a public FTP server and a "not-quite-warez server" both of which extensively used file compression and the scanned image archive. The UNIX software developer disks had particularly low entropy because of vast amounts of source code in ASCII. My guess is that an attacker who would have access to these distribution curves for his target data would be very likely to also know more detailed/specific things about it, and that informatio would likely be much more helpful to his attack. Under the assumption that the disk is flushed with PRNG bits initially, and that the output of the cipher has high entropy too, I decided that trying to obscure these patterns, as well as the physical layout patterns of the storage managment (filesystem/ database) beyond the basic rotation, would just slow things down and not add any incremental security worth it. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 16:19:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7B3F16A4CE for ; Sat, 5 Mar 2005 16:19:40 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C04343D2F for ; Sat, 5 Mar 2005 16:19:40 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id 8F963FB286; Sat, 5 Mar 2005 11:19:39 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 88BBEFB27C; Sat, 5 Mar 2005 11:19:38 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 8A9743BFF12; Sat, 5 Mar 2005 11:19:32 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "ALeine" In-Reply-To: Your message of "Fri, 04 Mar 2005 10:55:48 PST." <200503041855.j24Itmfa032915@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Mar 2005 11:19:32 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050305161932.8A9743BFF12@berkshire.machshav.com> X-Mailman-Approved-At: Sun, 06 Mar 2005 12:58:25 +0000 cc: elric@imrryr.org cc: abuse@spamalicious.com cc: briggs@NetBSD.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 16:19:40 -0000 > >> 1) If you're doing analysis of a cold disk, it is ~trivial to tell >> the difference between a sector that has been written only once and >> a sector that has been rewritten. > >This is hardly trivial, you are basing your statement on the false >assumption that one cannot or will not do anything to protect the >encrypted image after the initialization. One can do a lot. > >For example, one can regularly scrub the unused areas around the >encrypted image (padding) with dd(1) using if=/dev/{u,}random and >similar. This can be fully automated with a cron job. > >One can also regularly scatter files with misleading names and >contents. etc. I think we need to be careful about phrases like "one can". I decided to stop supposing and gather some real data, so I wrote some analysis tools to measure the entropy of disk drives. I need to rewrite some of my tools and do a lot more analysis, but I think the results thus far are quite interesting. See http://www.cs.columbia.edu/~smb/rawdisk-entropy.ps There are two plots shown in the file. In both, the X axis is the entropy per sector (to two digits past the decimal point); the Y axis is the number of sectors that had that entropy. The first graph is of the entire NetBSD partition on my laptop. The only difference is that in the second, graph, I deleted the sectors with 0 entropy -- those were about 25% of the disk. (The disk is 2/3 full.) For calibration, I ran the same tool on 100,000 blocks of /dev/urandom output; the lowest entropy I got was about 7.4. Quantitatively, if you pick a block at random and use 7.4 as the cut-off for "random", you have about a 77% chance of hitting a non-random, i.e., plaintext block. I have some directories which I suspect have files of high entropy (mp3s, jpgs, .tgz files, a cgd partition); if I exclude those -- a not-unreasonable move for certain classes of disks -- you have a 98% chance of hitting a plaintext block. (Caveat: that analysis is very preliminary; I have not yet actually measured the entropy of those file types. Note the large hump between 3.5 and 6 on the second graph; it may be that some of those directories fall in there.) Anyway -- the moral of the story is that you really need to analyze your environment and your threat model when designing crypto. The answer to SAN link eavesdropping might be IPsec or link encryptors; the answer to cleaning lady attacks might be cleared personnel, two party rules, or other non-crypto solutions. But don't assume, and don't say "one can" or "one should". (As a footnote, I realized that my own cgd "partition" (via vnd) was created from /dev/zero instead of /dev/urandom; the result is that the entropy of the file itself reveals almost exactly how much of the cgd partition is in use. I'll have to correct that....) --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 17:47:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D06C216A4CE for ; Sat, 5 Mar 2005 17:47:52 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2386543D49 for ; Sat, 5 Mar 2005 17:47:52 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id 916BAFB281; Sat, 5 Mar 2005 12:47:51 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0614DFB266; Sat, 5 Mar 2005 12:47:51 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 2CA9A3BFF12; Sat, 5 Mar 2005 12:47:43 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "ALeine" In-Reply-To: Your message of "Fri, 04 Mar 2005 13:28:17 PST." <200503042128.j24LSH4d035277@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Mar 2005 12:47:43 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050305174743.2CA9A3BFF12@berkshire.machshav.com> X-Mailman-Approved-At: Sun, 06 Mar 2005 12:58:25 +0000 cc: elric@imrryr.org cc: abuse@spamalicious.com cc: briggs@NetBSD.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 17:47:52 -0000 In message <200503042128.j24LSH4d035277@marlena.vvi.at>, "ALeine" writes: >Could you make the tools you used publically available? I would very >much like to run that kind of analysis on my disks, especially now >that I'm planning the implementation of the GBDE changes I proposed. I will eventually, but there's nothing in shape to release right now. It's proof-of-concept C, a few awk scripts, and a bunch of hand-typed awk and gnuplot. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 18:43:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9A9616A4CE for ; Sat, 5 Mar 2005 18:43:28 +0000 (GMT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45C2D43D1D for ; Sat, 5 Mar 2005 18:43:28 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id j25IhJm1003004; Sat, 5 Mar 2005 12:43:19 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id j25IhJjt003003; Sat, 5 Mar 2005 12:43:19 -0600 (CST) (envelope-from tinguely) Date: Sat, 5 Mar 2005 12:43:19 -0600 (CST) From: Mark Tinguely Message-Id: <200503051843.j25IhJjt003003@casselton.net> To: hackers@freebsd.org, kcai@cs.ubc.ca In-Reply-To: X-Spam-Status: No, score=1.4 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ccn.casselton.net X-Mailman-Approved-At: Sun, 06 Mar 2005 12:58:25 +0000 cc: penoff@cs.ubc.ca Subject: Re: FreeBSD 4.11-RELEASE & SACK X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 18:43:28 -0000 There was a posting to a FreeBSD mailing list (I believe -net, check the archives) within the last couple months with the FreeBSD 4.x SACK difference. Warning: There have been some serious fixes to SACK on FreeBSD current since that posting. I did not try the SACK changes because of the fixes that were, at that time, forthcoming. --Mark Tinguely. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 20:04:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2555416A4CE for ; Sat, 5 Mar 2005 20:04:25 +0000 (GMT) Received: from wiredyne.com (adsl-63-194-89-150.dsl.snfc21.pacbell.net [63.194.89.150]) by mx1.FreeBSD.org (Postfix) with SMTP id AF7D843D1D for ; Sat, 5 Mar 2005 20:04:24 +0000 (GMT) (envelope-from pdh@wiredyne.com) Received: (qmail 9981 invoked by uid 1009); 5 Mar 2005 20:04:46 -0000 Date: 5 Mar 2005 20:04:46 -0000 Message-ID: <20050305200446.9980.qmail@wiredyne.com> From: Peter Hendrickson To: Thor Lancelot Simon In-Reply-To: <20050303181044.GA6732@panix.com> References: <20050303165730.8931C3BFDBA@berkshire.machshav.com> <9418.1109872131@critter.freebsd.dk> <20050303181044.GA6732@panix.com> X-Mailman-Approved-At: Sun, 06 Mar 2005 12:58:25 +0000 cc: tech-security@netbsd.org cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 20:04:25 -0000 Thor Lancelot Simon wrote: > I note that GBDE uses a number of algorithms in ways that are not > consistent with their design purposes. For instance, it truncates a > non-keyed hash (SHA512); the fact that this is not necessarily a > good idea is one of the major motivators for the design of HMAC. This is a widely accepted practice. RFC 2631 generates keys this way, using SHA-1. And aren't most /dev/random implementations outputting SHA-1 hashes? Users are expected to treat the output as a stream of random bits, so in most cases truncated hashes are used. It may not be a good idea, but Poul-Henning Kamp has not made a radical design decision here. Also, a problem with a keyed hash may not be a problem when generating key material from a secret. Let's say we use this as a keyed hash function: SHA-1(k || p). (k the key, p the plaintext to be authenticated.) This has the bad property that the attacker can easily forge signatures of the form SHA-1(k || p || x) where x is attacker supplied material. (The attacker does not need to know the value of k.) But this is a reasonable way to generate key material to drive a cipher. I will note that Kamp's design differs from RFC 2631's approach. Section 7.1 ("From passphrase to master key") of his paper describes the generation of three keys from one hash. RFC 2631 would generate these keys by doing three hash computations with a counter used to vary the input slightly and using the leftmost bits of the result. Intuitively, I like RFC 2631's approach better, but it would be interesting to know if there's a better reason to do it that way. Peter From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 21:06:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBE6916A4CE for ; Sat, 5 Mar 2005 21:06:37 +0000 (GMT) Received: from hiroshima.ihack.net (209-6-103-199.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.103.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED8C743D4C for ; Sat, 5 Mar 2005 21:06:36 +0000 (GMT) (envelope-from abuse@spamalicious.com) Received: by hiroshima.ihack.net (Postfix, from userid 27753) id 4DF2C2A65EB; Sat, 5 Mar 2005 21:06:05 +0000 (UTC) From: "Charles M. Hannum" Organization: By Noon Software, Inc. To: "ALeine" Date: Sat, 5 Mar 2005 21:06:04 +0000 User-Agent: KMail/1.7 References: <200503041855.j24Itmfa032915@marlena.vvi.at> In-Reply-To: <200503041855.j24Itmfa032915@marlena.vvi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503052106.05001.abuse@spamalicious.com> X-Mailman-Approved-At: Sun, 06 Mar 2005 12:58:41 +0000 cc: elric@imrryr.org cc: briggs@netbsd.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 21:06:37 -0000 On Friday 04 March 2005 18:55, ALeine wrote: > > 1) If you're doing analysis of a cold disk, it is ~trivial to tell > > the difference between a sector that has been written only once and > > a sector that has been rewritten. > > This is hardly trivial, you are basing your statement on the false > assumption that one cannot or will not do anything to protect the > encrypted image after the initialization. One can do a lot. I'm basing my statement on the assumption that people will use GBDE. I see nothing in GBDE to prevent such analysis. > > 2) When used in a SAN environment, or an environment where > > multiple accesses to the drive can be done over time, it is > > possible to determine this fairly quickly using traffic analysis. > > The GBDE paper even touches on this in section 10.3. Have you > > read it? > > First of all, protection against traffic analysis on a SAN is in > the territory of hot disk protection and GBDE, as you must have > surely read, is designed for cold disk protection. No, actually, it's not. "Hot disk" protection as defined in the GBDE paper refers to breaking the GBDE partition *on the machine that's using it*, where you have the keys in memory. That's not even vaguely what I'm talking about. Furthermore, people *have* discussed using GBDE in a SAN environment. Also, I'm not talking about necessarily using the SAN as direct storage for the GBDE partition. It could, for example, be used to back it up. In either case, traffic analysis will find a lot of information -- e.g. I propose that just by looking at which sectors tend to be modified together, that the sector "rotation" and zone size can be discovered with usually no more than two snapshots (it depends on how much has been modified), and is therefore pretty much useless cryptographically. > SANs are by > definition high availability environments and as such have high > volume traffic, so if you have someone who has access to be able > to monitor that traffic and can also analyze such high volumes > of traffic and can also clone your entire SAN storage devices > unnoticed without causing a service disruption then you have > much bigger problems, so worrying about GBDE should be the > least of your concerns. :-) I am not talking about "cloning your entire SAN storage device". In reality, cloning a user's GBDE partition stored on a SAN would generally be trivial, as it would only be a small fraction of the SAN. > Second of all, the cleaning lady copy attack (described in section > 10.3), where someone can regularly make bit-wise copies of the > entire disk containing the encrypted image and determine the > location of sensitive structures by means of differential analysis > is not very practical. Actually, it's quite practical. It requires no hardware modification that might be noticed, and it only requires intermittent access to the machine. And as I said above, traffic analysis will yield considerable results toward breaking the encryption. Do you keep *your* laptop next to you 24/7? Very few people do. Some laptop manufacturers (e.g. Dell) even make it particularly easy to remove the disk. While you might claim that the dedication to study the user's behavior and mount such an attack is fanciful, I claim that it is not. Under observation, GBDE's additional techniques do not stand up to the claim of being "spook strength". From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 6 16:23:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F92616A4CE for ; Sun, 6 Mar 2005 16:23:03 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35EFA43D1F for ; Sun, 6 Mar 2005 16:23:03 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j25KRwoH055473; Sat, 5 Mar 2005 12:27:59 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j25KRmAF055472; Sat, 5 Mar 2005 12:27:48 -0800 (PST) (envelope-from www) Date: Sat, 5 Mar 2005 12:27:48 -0800 (PST) Message-Id: <200503052027.j25KRmAF055472@marlena.vvi.at> To: abuse@spamalicious.com From: "ALeine" cc: elric@imrryr.org cc: briggs@netbsd.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 16:23:03 -0000 abuse@spamalicious.com wrote: > > Second of all, the cleaning lady copy attack (described in section > > 10.3), where someone can regularly make bit-wise copies of the > > entire disk containing the encrypted image and determine the > > location of sensitive structures by means of differential analysis > > is not very practical. > > Actually, it's quite practical. It requires no hardware modification that > might be noticed, and it only requires intermittent access to the machine. > And as I said above, traffic analysis will yield considerable results toward > breaking the encryption. Do you keep *your* laptop next to you 24/7? Very > few people do. Some laptop manufacturers (e.g. Dell) even make it > particularly easy to remove the disk. Trying to prove your point by taking my statements out of context is not a very good way to argue a point. Let me reiterate: Second of all, the cleaning lady copy attack (described in section 10.3), where someone can regularly make bit-wise copies of the entire disk containing the encrypted image and determine the location of sensitive structures by means of differential analysis is not very practical. If someone has that kind of access to your computer then they are more likely to use a hardware keylogger and intercept the passphrase. I never implied this kind of attack would be impossible, it is in fact probable. What I did imply is that this kind of attack is less practical than simply using a keylogger to intercept the passphrase. If you assume that you are dealing with an attacker capable of differential analysis, you can also safely assume that such an attacker knows that employing a keylogger would be an easier way to achieve the same goal, therefore the attacker would be more likely to resort to using a keylogger than differential analysis. That is, if we also assume the attacker is sane and not a masochist. > While you might claim that the dedication to study the user's behavior and > mount such an attack is fanciful, I claim that it is not. Under observation, > GBDE's additional techniques do not stand up to the claim of being "spook > strength". I never made such a claim, you are missing the point. What I am saying is that as long as there are more practical ways of attacking GBDE in the particular scenario where an attacker has access to the cold disk in a way that enables that attacker to, among other possibilities, make bit-wise copies of the disk on a regular basis in order to perform differential analysis, such an attacker is more likely to resort to employing other easier methods first. You cannot use the argument of susceptibility to differential analysis against GBDE without using the same argument against CGD. In fact, CGD is even more susceptible to such analysis because eventhough it employs AES 256, it does nothing to obscure the location of sensitive sectors, while GBDE employs several mechanisms to achieve that goal and to also severely localize the extent and impact of a potential compromise resulting from differential analysis. Your point is therefore moot. I also believe that it would be beneficial to implement regular rewriting of randomly picked lock sector(s) at random times during a user specified interval (up to x rewrites within n seconds) in order to further obscure the write pattern and provide additional protection for lock sectors. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 03:34:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 863FB16A4CE for ; Mon, 7 Mar 2005 03:34:37 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.46.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3560B43D1D for ; Mon, 7 Mar 2005 03:34:37 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.135]) by smtp.ucla.edu (8.13.2/8.13.2) with ESMTP id j273Yau6003708 for ; Sun, 6 Mar 2005 19:34:36 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j273Ya71026187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 Mar 2005 19:34:36 -0800 Message-ID: <000801c522c6$ad04a940$abe243a4@ash> From: "Ashwin Chandra" To: Date: Sun, 6 Mar 2005 19:35:14 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0.152 X-Scanned-By: smtp.ucla.edu on 169.232.46.136 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: taking a process and all associated threads off the run queue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 03:34:37 -0000 Hi all, I am trying to modify the scheduler to take off some processes (such as = those generated by a forkbomb ... malicious) off the run queue. I have = been looking into the scheduler and proc.h and see there is one way by = putting threads on the 'suspension' queue. I am not sure if this is the = same thing. But anyway, I modified sched_cpu in sched_4bsd.c to look = something like this: =20 FOREACH_THREAD_IN_PROC(p, td) { if(p->p_km_switch =3D=3D P_NON_RUN) { if( !TD_IS_SUSPENDED(td) ) { //thread_suspend_one(td); printf("suspending thread associated with = %s\n", td->td_ksegrp->kg_proc->p_comm); TD_SET_SUSPENDED(td); } } else if(p->p_km_switch =3D=3D P_RUN) { if(TD_IS_SUSPENDED(td)) { //thread_unsuspend_one(td); printf("clearing suspending thread = associated with %s\n", td->td_ksegrp->kg_proc->p_comm); TD_CLR_SUSPENDED(td); } } } the p_km_switch turns on when a process exceeds a certain threshold of = memory usage and context switching. If the threads associated with this = process are suspended, and the system becomes less loady, then they are = unsuspended (The P_RUN flag is set externally). So I tried this out, and = it seems to sort of work although when I print out the p->p_suspcount, = it says its 0, so I am not sure if this is even working right. Im sure you guys know the scheduler much better than I do. What would be = the best way to modify the scheduler so that given a certain NON_RUN = flag I can pretty much take a process of the run queue and then later = put it back on when the system is less loaded? Thanks a lot, Ash From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 06:01:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6233116A4CE for ; Mon, 7 Mar 2005 06:01:52 +0000 (GMT) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E00643D2F for ; Mon, 7 Mar 2005 06:01:52 +0000 (GMT) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.1/8.13.1) with ESMTP id j2761jbJ034421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 22:01:45 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.1/8.13.1/Submit) id j2761j24034420; Sun, 6 Mar 2005 22:01:45 -0800 (PST) (envelope-from steve) Message-Id: <200503070601.j2761j24034420@wattres.watt.com> X-Newsgroups: local.freebsd-hackers In-Reply-To: <20050306101423.44745.qmail@web52702.mail.yahoo.com> Organization: Watt Consultants From: steve@Watt.COM (Steve Watt) Date: Sun, 6 Mar 2005 22:01:44 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: kamalp@acm.org X-Archived: 1110175305.788270349@wattres.Watt.COM X-Virus-Scanned: ClamAV 0.83/749/Sun Mar 6 14:29:08 2005 on wattres.Watt.COM X-Virus-Status: Clean cc: hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 06:01:52 -0000 In <20050306101423.44745.qmail@web52702.mail.yahoo.com>, Kamal R. Prasad wrote: >--- Steve Watt wrote: [ snip ] >> NPTL is a particular (less brain damaged than >> LinuxThreads) >> implementation of the POSIX thread standard. >> >> Likewise, scheduler activations are a decent >> implementation of > >doesn't that have a problem with M:N performance (M |= >N)? "Problem"? Scheduler activations may be used to build M:N systems, but that is not a requirement -- you can easily build a 1:1 (all threads are system contention scope) system with activations. Admittedly, at this point in industry experience, most threads experts will say that M:N threading usually isn't worth the implementation headaches. But there are definite classes of problem, often having to do with certain styles of user-interface design or a less-than-optimal object system, where thousands of threads are a useful developer convenience. Very many processes with thousands of threads in them will drag down a 1:1 system pretty rapidly. >> Julian> so how does that differ from what we have >> ... a >> Julian> native pthreads library? >> >> Kamal>I just said if it was conformant with NPTL, >> thread and >> Kamal>process scheduling would co-exist. >> >> Uh, as far as I understand, in NPTL, each thread >> gets a scheduler >> slot, and it is my understanding that there is >> nothing to protect >> against the issue that Julian is asking about (1000 >> threads of a >> single process *do* get 1000 times the time slices). >> > >(AFAIK) Referring to the POSIX std (and not NPTL) -if >threads were defined within process scope and not >system scope -the scheduling attributes of the process >will apply. Yes, and a system that has both system scope and process scope is usually called an M:N system. I will grant that it is possible for the kernel to be aware of all of the threads in the system (i.e. a 1:1 model) but handle contention scope correctly. I don't think anyone has built such a system, but would be happy to be proven wrong -- it'd be a useful advancement of the art. One challenge is accounting for time on threads that don't do much work when awakened before going back to sleep -- if there are 1000 process-scope threads, and all of them run for half a millisecond and block, in the aggregate you need to charge the process the entire 500mS, or the timesharing characteristics won't come out right. It's somewhat challenging to do that charging cheaply. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 11:34:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99CF216A4CE for ; Mon, 7 Mar 2005 11:34:59 +0000 (GMT) Received: from web52705.mail.yahoo.com (web52705.mail.yahoo.com [206.190.39.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 23E6F43D5A for ; Mon, 7 Mar 2005 11:34:59 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 7713 invoked by uid 60001); 7 Mar 2005 11:34:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=YtwsL6oREv7/APHZe2qBDUGK2gzLpp+ChLBt7izUp4TbPD4Kd0gCh92s9/4kjJEzGL0l/Np7RPnhahhAu+ijI1gipkPWZJrUrA2CLm6gJA9SrBGZxZRxsQ6ZbicDdr2rkto1/dgQLjus468xu2nA7E/7IpJrYABpNwW1rwGst00= ; Message-ID: <20050307113458.7711.qmail@web52705.mail.yahoo.com> Received: from [202.91.78.244] by web52705.mail.yahoo.com via HTTP; Mon, 07 Mar 2005 03:34:58 PST Date: Mon, 7 Mar 2005 03:34:58 -0800 (PST) From: "Kamal R. Prasad" To: Steve Watt In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 11:34:59 -0000 --- Steve Watt wrote: > In > <20050306101423.44745.qmail@web52702.mail.yahoo.com>, > >N)? > > "Problem"? Scheduler activations may be used to > build M:N > systems, but that is not a requirement -- you can > easily > build a 1:1 (all threads are system contention > scope) system > with activations. > But the POSIX std allows one to specify that the thread be either process scope or system scope, and if some of them are system/process scope -that leads to an M:N system. > Admittedly, at this point in industry experience, > most > threads experts will say that M:N threading usually > isn't > worth the implementation headaches. But there are Hmm -so no implementation can provide a good M:N system. [snip] > convenience. Very many processes with thousands of > threads > in them will drag down a 1:1 system pretty rapidly. > I get the idea that not everyone in the pthreads-user community is content with a 1:1 model (though I would be). [snip] > handle contention scope correctly. I don't think > anyone > has built such a system, but would be happy to be > proven > wrong -- it'd be a useful advancement of the art. Isn't a system supporting both process/system scope a POSIX requirement? BTW -the std sounds weird to me at times. They want to treat a process as a shell with a single (hypothetical) thread in it -and their scheduling classes don't have a 1:1 correspondence to the unix scheduler. SCHED_RR is a realtime scheduling class but I mistook it for a round robin scheduler:-). > One > challenge is accounting for time on threads that > don't do > much work when awakened before going back to sleep If every kernel thread were to be treated at par with a process, we wouldn't need a special algorithm. regards -kamal ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 6 16:54:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACE816A4CE for ; Sun, 6 Mar 2005 16:54:24 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id E16E343D53 for ; Sun, 6 Mar 2005 16:54:23 +0000 (GMT) (envelope-from das@CSAIL.MIT.EDU) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j26GrNpr024195; Sun, 6 Mar 2005 11:53:23 -0500 (EST) (envelope-from das@CSAIL.MIT.EDU) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j26GrMcX024194; Sun, 6 Mar 2005 11:53:22 -0500 (EST) (envelope-from das@CSAIL.MIT.EDU) Date: Sun, 6 Mar 2005 11:53:21 -0500 From: David Schultz To: "Perry E. Metzger" Message-ID: <20050306165321.GA24134@VARK.MIT.EDU> Mail-Followup-To: "Perry E. Metzger" , ALeine , tech-security@NetBSD.org, phk@phk.freebsd.dk, hackers@freebsd.org, elric@imrryr.org, ticso@cicely.de References: <200503022348.j22Nm48I086259@marlena.vvi.at> <873bvcjw90.fsf@snark.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873bvcjw90.fsf@snark.piermont.com> X-Mailman-Approved-At: Mon, 07 Mar 2005 12:55:25 +0000 cc: ALeine cc: elric@imrryr.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 16:54:25 -0000 On Thu, Mar 03, 2005, Perry E. Metzger wrote: > No, I am not. PHK invented new cryptographic modes for his work. The > fact that he does not understand this is part of the problem. Hi Perry, You've brought up this claim at several points in this thread. Would you be willing to be more specific? I apologize if I missed an explanation in the noise. More generally, I think a well considered review from you would be more beneficial than all this sniping. If your principal objection is unproven assumptions in GBDE, then it would be constructive to reason about which aspects of the system are provably secure and which are heuristic. If you believe GBDE has irreparable flaws, FUD tactics should not be required to demonstrate them. My initial impression from reading the paper is as follows: - The use of AES/CBC to encrypt key and data sectors seems to be entirely standard, provided that the IV is randomized as per footnote 6. Subject to the security of key generation and of AES, this aspect of the design appears to be secure. - The mechanism by which GBDE prevents information from the master key from leaking to the sector keys appears to be largely heuristic. o On the one hand, this means it would be difficult to prove that an adversary who can recover several sector keys cannot use this knowledge to easily recover the master key. o On the other hand, per-sector keying may significantly increase the work factor of a potential attacker in the event of a weakness in AES related to a large ciphertext sample, so it nevertheless seems superior to using the same key for everything. Therefore, this seems like a laudable design goal. o I'm not sure I believe the claim that the use of MD5 to generate so-called key-keys won't weaken security. As a rather extreme example, suppose that it was discovered that on random input, an MD5 output only has 70 bits of entropy. Then it might be relatively easy for an adversary to recover sector keys without knowing the master key. (Granted, this would constitute a much stronger break in MD5 than is currently known.) - The pseudorandom sector remapping is an additional layer that a would-be attacker would need to break, although in theoretical terms it probably adds very little. In particular, it is prudent to assume that the adversary already knows the plaintext contents of a substantial fraction of the disk, and in such cases, the randomization makes little difference. The randomization might be a more interesting property in the context of a semi-trusted remote block server, but that is out of scope. Of course, the standard disclaimer applies to all of this. Further, I don't claim to be an expert in this area, nor do I claim to have performed a detailed analysis of GBDE. As both you and phk have already stated, additional reviews would definitely be a good thing. --David From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 6 22:45:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD6E016A4CE for ; Sun, 6 Mar 2005 22:45:46 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8841243D2D for ; Sun, 6 Mar 2005 22:45:45 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 56E50D9877; Sun, 6 Mar 2005 17:45:44 -0500 (EST) To: das@CSAIL.MIT.EDU References: <200503022348.j22Nm48I086259@marlena.vvi.at> <873bvcjw90.fsf@snark.piermont.com> <20050306165321.GA24134@VARK.MIT.EDU> From: "Perry E. Metzger" Date: Sun, 06 Mar 2005 17:45:44 -0500 In-Reply-To: <20050306165321.GA24134@VARK.MIT.EDU> (David Schultz's message of "Sun, 6 Mar 2005 11:53:21 -0500") Message-ID: <87is44cs13.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 07 Mar 2005 12:55:25 +0000 cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 22:45:46 -0000 David Schultz writes: > On Thu, Mar 03, 2005, Perry E. Metzger wrote: >> No, I am not. PHK invented new cryptographic modes for his work. The >> fact that he does not understand this is part of the problem. > > Hi Perry, > > You've brought up this claim at several points in this thread. > Would you be willing to be more specific? Have a look at the giant diagram in section 7.5. He's effectively built a complicated key scheduling algorithm. It is unclear if this algorithm is particularly good -- Roland has now pointed out in an informal paper he has put together that because the master key is 256 bytes from a uniform distribution, one can expect that the probability distribution of bytes selected from those 256 bytes and input into the key key portion of the algorithm is rather different than if it too was from a merely uniform distribution. For example, the probability of duplicate bytes in the input is different than if you were drawing from an infinite pool -- the infinite pool will have all 256 elements, but the master key will probably have ~160 distinct values. The key keys, therefore, are not in fact as different as one might like. (The analysis on this is still pretty early but it looks promising.) This is just one example of the sort of thing PHK has done here. He doesn't believe that he's done anything that might be described as a new cryptographic mode but he has. > I apologize if I missed an explanation in the noise. More > generally, I think a well considered review from you would be more > beneficial than all this sniping. I personally don't have the energy for it, but other people appear to be working on that. Steve Bellovin posted a note to the Cryptography mailing list and there have already been several replies. All are pretty informal at this point, but the gist of what is coming from new eyes seems to be very similar to what came from the old ones. -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 13:07:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7557516A4CE for ; Mon, 7 Mar 2005 13:07:03 +0000 (GMT) Received: from pd4mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3446143D1F for ; Mon, 7 Mar 2005 13:07:03 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd5mr5so.prod.shaw.ca (pd5mr5so-qfe3.prod.shaw.ca [10.0.141.181]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ001DMGF9VS30@l-daemon> for hackers@freebsd.org; Mon, 07 Mar 2005 06:06:45 -0700 (MST) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd5mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ00LP0GFAWLK0@pd5mr5so.prod.shaw.ca> for hackers@freebsd.org; Mon, 07 Mar 2005 06:06:46 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICZ00332GF9RG@l-daemon> for hackers@freebsd.org; Mon, 07 Mar 2005 06:06:45 -0700 (MST) Date: Mon, 07 Mar 2005 05:06:44 -0800 From: Colin Percival In-reply-to: <20050306165321.GA24134@VARK.MIT.EDU> To: David Schultz Message-id: <422C51E4.6030104@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <200503022348.j22Nm48I086259@marlena.vvi.at> <873bvcjw90.fsf@snark.piermont.com> <20050306165321.GA24134@VARK.MIT.EDU> User-Agent: Mozilla Thunderbird 1.0 (X11/20050302) cc: ALeine cc: elric@imrryr.org cc: "Perry E. Metzger" cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 13:07:03 -0000 David Schultz wrote: > As a > rather extreme example, suppose that it was discovered that on > random input, an MD5 output only has 70 bits of entropy. Then > it might be relatively easy for an adversary to recover sector > keys without knowing the master key. (Granted, this would > constitute a much stronger break in MD5 than is currently known.) I'm not going to even touch the rest of this thread, but it is clear that MD5 has at least 100 bits of entropy, simply based on the lack of collisions resulting from hashing random data. (If you generate 2^n hashes randomly without finding a collision, then the hash must have at least ~~ 2n bits of entropy, and organized attempts to crack MD5 generated at least 2^50 hashes before the algorithmic break was found.) Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 16:40:27 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FD7E16A4CE for ; Mon, 7 Mar 2005 16:40:27 +0000 (GMT) Received: from cydem.org (S0106000103ce4c9c.ed.shawcable.net [68.149.254.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id C55D643D31 for ; Mon, 7 Mar 2005 16:40:26 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.68]) by cydem.org (Postfix/FreeBSD) with ESMTP id A78A3380B5; Mon, 7 Mar 2005 09:40:25 -0700 (MST) From: To: , Date: Mon, 7 Mar 2005 09:40:49 -0700 User-Agent: KMail/1.5.4 References: <200503052027.j25KRmAF055472@marlena.vvi.at> In-Reply-To: <200503052027.j25KRmAF055472@marlena.vvi.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503070940.49393.soralx@cydem.org> cc: aleine@austrosearch.net cc: phk@phk.freebsd.dk Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 16:40:27 -0000 > I also believe that it would be beneficial to implement regular rewriting > of randomly picked lock sector(s) at random times during a user specified > interval (up to x rewrites within n seconds) in order to further obscure > the write pattern and provide additional protection for lock sectors. > ALeine I agree. I would also add random reads (or specially designed, combined random reads and writes) to make traffic analysis and differential attacks a real PITA for the hacker (although this idea may not be very effective against a highly motivated and determined attacker, such as some government, for instance). Every data storage device has to be "hot", initially at least. Moreover, it is much better to keep the disk attached until the last minute before the attacker will get access to it, because this offers the user protection: deleting keys from a "cold" disk is not possible. Therefore, it is important for GBDE to protect "hot" disks as much as possible (including protection methods against "cleaning lady" copy & differential attacks, for SAN environments & other traffic analysis attacks, etc). BTW, PHK, why did you choose the scheme of encrypting offsets of lock sectors with part of key material and storing them somewhere, instead of just using part of the key material itself to determine the offsets? Timestamp: 0x422BE3D9 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 16:43:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70B8E16A4CE for ; Mon, 7 Mar 2005 16:43:06 +0000 (GMT) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F65343D60 for ; Mon, 7 Mar 2005 16:43:06 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from pd5mr5so.prod.shaw.ca (pd5mr5so-qfe3.prod.shaw.ca [10.0.141.181]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ00HQQQFD2WC0@l-daemon> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 09:42:49 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd5mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ00250QFD3590@pd5mr5so.prod.shaw.ca> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 09:42:49 -0700 (MST) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.68]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICZ005GYQFDJP@l-daemon> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 09:42:49 -0700 (MST) Date: Mon, 07 Mar 2005 09:43:13 -0700 From: soralx@cydem.org In-reply-to: <200503052027.j25KRmAF055472@marlena.vvi.at> To: freebsd-hackers@FreeBSD.ORG, tech-security@NetBSD.ORG Message-id: <200503070940.49393.soralx@cydem.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <200503052027.j25KRmAF055472@marlena.vvi.at> User-Agent: KMail/1.5.4 cc: aleine@austrosearch.net cc: phk@phk.freebsd.dk Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 16:43:06 -0000 > I also believe that it would be beneficial to implement regular rewriting > of randomly picked lock sector(s) at random times during a user specified > interval (up to x rewrites within n seconds) in order to further obscure > the write pattern and provide additional protection for lock sectors. > ALeine I agree. I would also add random reads (or specially designed, combined random reads and writes) to make traffic analysis and differential attacks a real PITA for the hacker (although this idea may not be very effective against a highly motivated and determined attacker, such as some government, for instance). Every data storage device has to be "hot", initially at least. Moreover, it is much better to keep the disk attached until the last minute before the attacker will get access to it, because this offers the user protection: deleting keys from a "cold" disk is not possible. Therefore, it is important for GBDE to protect "hot" disks as much as possible (including protection methods against "cleaning lady" copy & differential attacks, for SAN environments & other traffic analysis attacks, etc). BTW, PHK, why did you choose the scheme of encrypting offsets of lock sectors with part of key material and storing them somewhere, instead of just using part of the key material itself to determine the offsets? Timestamp: 0x422BE3D9 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 16:50:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C124316A4CE for ; Mon, 7 Mar 2005 16:50:15 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BA8C43D1D for ; Mon, 7 Mar 2005 16:50:15 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j27Gnoga018768; Mon, 7 Mar 2005 17:49:50 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: soralx@cydem.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 07 Mar 2005 09:40:49 MST." <200503070940.49393.soralx@cydem.org> Date: Mon, 07 Mar 2005 17:49:50 +0100 Message-ID: <18767.1110214190@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: aleine@austrosearch.net cc: freebsd-hackers@FreeBSD.ORG cc: tech-security@NetBSD.ORG Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 16:50:15 -0000 In message <200503070940.49393.soralx@cydem.org>, soralx@cydem.org writes: > >> I also believe that it would be beneficial to implement regular rewriting >> of randomly picked lock sector(s) at random times during a user specified >> interval (up to x rewrites within n seconds) in order to further obscure >> the write pattern and provide additional protection for lock sectors. >> ALeine > >I agree. I would also add random reads (or specially designed, combined >random reads and writes) to make traffic analysis and differential attacks >a real PITA for the hacker (although this idea may not be very effective >against a highly motivated and determined attacker, such as some government, >for instance). If you want to do something like this, you want to do sectorrenaming and journaling since that means you can only see that something was written but not what it was that was written. The performance cost can be considerable and the complexity formidable. There are incredibly many cornercases to handle. >BTW, PHK, why did you choose the scheme of encrypting offsets of lock >sectors with part of key material and storing them somewhere, instead >of just using part of the key material itself to determine the offsets? Because if I used part of the key material you would have to change the location of the lock sectors when you changed the key material. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 18:06:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7457516A4CE for ; Mon, 7 Mar 2005 18:06:33 +0000 (GMT) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 390EF43D54 for ; Mon, 7 Mar 2005 18:06:33 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from pd5mr7so.prod.shaw.ca (pd5mr7so-qfe3.prod.shaw.ca [10.0.141.183]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ005XTUAW5M50@l-daemon> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 11:06:32 -0700 (MST) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd5mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICZ00D94UAW90H0@pd5mr7so.prod.shaw.ca> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 11:06:32 -0700 (MST) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.68]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICZ00E2FUAV85@l-daemon> for freebsd-hackers@FreeBSD.ORG; Mon, 07 Mar 2005 11:06:32 -0700 (MST) Date: Mon, 07 Mar 2005 11:06:56 -0700 From: soralx@cydem.org In-reply-to: <18767.1110214190@critter.freebsd.dk> To: freebsd-hackers@FreeBSD.ORG, tech-security@NetBSD.ORG Message-id: <200503071106.56075.soralx@cydem.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <18767.1110214190@critter.freebsd.dk> User-Agent: KMail/1.5.4 cc: aleine@austrosearch.net cc: phk@phk.freebsd.dk Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 18:06:33 -0000 > >I agree. I would also add random reads (or specially designed, combined > >random reads and writes) to make traffic analysis and differential attacks > >a real PITA for the hacker (although this idea may not be very effective > >against a highly motivated and determined attacker, such as some > > government, for instance). > > If you want to do something like this, you want to do sectorrenaming > and journaling since that means you can only see that something > was written but not what it was that was written. So you think that just adding specially crafted, random reads/writes will have no significant positive impact on security of "hot" disks? > The performance cost can be considerable and the complexity formidable. > There are incredibly many cornercases to handle. But you do not deny that providing strong protection for "hot" disks is very important? After all, user protection is only available when the disk is hot. Speaking of user protection, how did you implement the procedure of erasing keys? Did you account for the properties of magnetic media and RAM that make data recovery possible? See, for example: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Timestamp: 0x422C930D [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 19:11:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B14B016A4CE for ; Mon, 7 Mar 2005 19:11:06 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3EB343D41 for ; Mon, 7 Mar 2005 19:11:05 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j27JAnRb000903; Mon, 7 Mar 2005 20:10:49 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: soralx@cydem.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 07 Mar 2005 11:06:56 MST." <200503071106.56075.soralx@cydem.org> Date: Mon, 07 Mar 2005 20:10:49 +0100 Message-ID: <902.1110222649@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: aleine@austrosearch.net cc: freebsd-hackers@FreeBSD.ORG cc: tech-security@NetBSD.ORG Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 19:11:06 -0000 In message <200503071106.56075.soralx@cydem.org>, soralx@cydem.org writes: >> If you want to do something like this, you want to do sectorrenaming >> and journaling since that means you can only see that something >> was written but not what it was that was written. > >So you think that just adding specially crafted, random reads/writes >will have no significant positive impact on security of "hot" disks? No I don't think so, because I tried it and were able to see straight through it myself. The trouble is that normal disk activity is not random. Randomness sticks out like a sore thumb in any sort of analysis, this is why plausible denial of existence of encrypted data is so hard that it is almost impossible when faced with a good adversary. >> The performance cost can be considerable and the complexity formidable. >> There are incredibly many cornercases to handle. > >But you do not deny that providing strong protection for "hot" disks >is very important? After all, user protection is only available when >the disk is hot. It is very important, but it is also a task which is very formidable in comparison with protecting cold disks. (Hint: attend BSDcan2005). >Speaking of user protection, how did you implement the procedure of >erasing keys? Did you account for the properties of magnetic media >and RAM that make data recovery possible? See, for example: >http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html No I did not, because there is no reliable way to counter it from software. There may have been once upon a time when that paper was written 10 years ago (although I seriously doubt the actual efficiency of the proposed schedules), but these days with Giant Magnetoresitive head technology and Partial Response Maximum Likelyhood decoding you can write and write and write and you will have no idea if it works or not. Bad sector forwarding is another issue in this area. There are commercial companies who have specialized in recovering deleted data from trackfringes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 20:58:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AE8416A4CE for ; Mon, 7 Mar 2005 20:58:29 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id B641B43D1D for ; Mon, 7 Mar 2005 20:58:28 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j2713FoH083596; Sun, 6 Mar 2005 17:03:22 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j27138Kf083595; Sun, 6 Mar 2005 17:03:08 -0800 (PST) (envelope-from www) Date: Sun, 6 Mar 2005 17:03:08 -0800 (PST) Message-Id: <200503070103.j27138Kf083595@marlena.vvi.at> To: soralx@cydem.org From: "ALeine" cc: freebsd-hackers@FreeBSD.ORG cc: phk@phk.freebsd.dk cc: tech-security@NetBSD.ORG Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 20:58:29 -0000 soralx@cydem.org wrote: > > >I agree. I would also add random reads (or specially designed, combined > > >random reads and writes) to make traffic analysis and differential attacks > > >a real PITA for the hacker (although this idea may not be very effective > > >against a highly motivated and determined attacker, such as some > > > government, for instance). > > > > If you want to do something like this, you want to do sectorrenaming > > and journaling since that means you can only see that something > > was written but not what it was that was written. Hot disk protection is something that should not to be implemented as an afterthought, it should be a known and well understood and analyzed requirement before any design can take place. I believe there is no need to use journaling to obscure the write pattern in order to better protect the lock sectors. An attacker who can regularly copy and analyze the disk for sectors which have been written could, over time, use that knowledge to locate the lock sectors basing the analysis on the assumption that lock sectors are not rewritten. That is why I believe adding such rewriting would be beneficial, but under the assumption that it would be done carefully, meaning that one would never rewrite just the lock sector but a much larger randomly sized block which would be picked in such a way that the lock sector would be at a random offset inside that block. One would also not rewrite the block if there were no disk writing taking place within a certain sector range in order not to reveal the location of a lock sector located on some remote part of the disk that does not get any write activity at all. For this reason I believe that lock sector rewrites should tag along with write operations occuring near lock sectors. If one were to then employ this mechanism to randomly rewrite other parts of the disk one could prevent an attacker from assuming that rewritten but unchanged blocks contain at least one of the lock sectors. These rewrites would not pose a threat to data integrity since the same data would be written to the same locations, but they would cause a slight performance drop. I say slight because the random rewrites of sectors other than lock sectors could be done at times of low disk activity and their frequency could be set by the user. > Speaking of user protection, how did you implement the procedure of > erasing keys? Did you account for the properties of magnetic media > and RAM that make data recovery possible? You already got the short answer: no. You can find the reasoning behind that decision in the section 4.1 of PHK's paper, but to summarize: this approach is mainly based on the assumptions that one would need to be able to destroy the keys quickly and that one would be able to provide positive proof that the keys had been destroyed. There are currently two destruction operations available: - destroy: destroys one lock sector by blanking the following fields with zeros: - sector0: byte offset of the 1st byte used - sectorN: byte offset of the 1st byte not used - keyoffset: byte offset by which the image is skewed - flags - the master key itself The fields containing offsets (lsector[G_BDE_MAXKEYS]) of all the other lock sectors are overwritten with ones (bitwise). Everything else (the salt, etc.) is left intact. Only one write takes place. - nuke: destroys all copies of the master key by completely overwriting all lock sectors with zeros. One write per lock sector takes place. The last time I checked the gbde(8) man page appeared to be missing info on the nuke operation. Should this be updated or will the update be done after the changes are finalized (I see some mention of the blast operation in the source code)? I also believe it would be a good idea to scrub the lock sector(s) with random garbage first and then as the last step perform the kind of blanking described above. Perhaps there could be an option for regular and emergency destruction. In an emergency you cannot afford to do the random garbage rewriting, but otherwise one could choose to scrub the lock sectors first in a series of larger randomly sized block rewrites as described above. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 21:08:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6634416A4CE for ; Mon, 7 Mar 2005 21:08:31 +0000 (GMT) Received: from cydem.org (S0106000103ce4c9c.ed.shawcable.net [68.149.254.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E17443D2F for ; Mon, 7 Mar 2005 21:08:30 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.68]) by cydem.org (Postfix/FreeBSD) with ESMTP id 6CE9D380B5; Mon, 7 Mar 2005 14:08:29 -0700 (MST) From: To: , Date: Mon, 7 Mar 2005 14:08:53 -0700 User-Agent: KMail/1.5.4 References: <902.1110222649@critter.freebsd.dk> In-Reply-To: <902.1110222649@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503071408.53733.soralx@cydem.org> cc: aleine@austrosearch.net cc: phk@phk.freebsd.dk Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 21:08:31 -0000 > >> If you want to do something like this, you want to do sectorrenaming > >> and journaling since that means you can only see that something > >> was written but not what it was that was written. > > > >So you think that just adding specially crafted, random reads/writes > >will have no significant positive impact on security of "hot" disks? > > No I don't think so, because I tried it and were able to see straight > through it myself. The trouble is that normal disk activity is not > random. > > Randomness sticks out like a sore thumb in any sort of analysis, this > is why plausible denial of existence of encrypted data is so hard > that it is almost impossible when faced with a good adversary. The main goal of the idea was not to hide the encrypted slice (which would be indeed extremely hard), but to help obscure the locations of GBDE's sensitive sectors. It is true that, as you said, completely random queries to the disk can be identified and filtered out by an expert adversary, but it will be much more of a challenge (or at least a significant difficulty) for him when researching the disk structure (using snapshots, traffick analysis, etc) if the following example points are implemented: - randomized (but not completely random) rewrites of lock sectors; perhaps a lock sector could be rewritten intermittently when a nearby data sector is written, so that the attacker is either fooled into thinking that it can't be a lock sector, or will know that statistical analysis on the disk will not yield lock sectors' locations. - randomized (user-configurable) and out-of-sequence reads and/or writes of key sectors so that it will be harder to figure out zone size and offset. These are just an oversimplified approximation of the concept. Hmm... Suddenly the idea doesn't seem so good anymore. Likely it will cause more PITA to the developer than to the attacker. The attacker would still be able to gather some info about the filesystem (superblock locations, maybe even inode locations, etc), and this even bigger threat can be prevented only by using journalling & sectorrenaming. > >But you do not deny that providing strong protection for "hot" disks > >is very important? After all, user protection is only available when > >the disk is hot. > It is very important, but it is also a task which is very formidable > in comparison with protecting cold disks. When done properly and right from the start - yes, but IMO there always will be some for improvement which may be added with time, so protection of "hot" disks should not be ignored. Seeing that you agree to this, now I'm not worried that GBDE is not or will be not as strong as reasonably possible, in all modes of operation. > (Hint: attend BSDcan2005). 3.5 thousand km one way may be a bit too long a ride for me :) this would be at least a 10-day trip... > >Speaking of user protection, how did you implement the procedure of > >erasing keys? Did you account for the properties of magnetic media > >and RAM that make data recovery possible? See, for example: > >http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > No I did not, because there is no reliable way to counter it from > software. > > There may have been once upon a time when that paper was written > 10 years ago (although I seriously doubt the actual efficiency of > the proposed schedules), but these days with Giant Magnetoresitive head > technology and Partial Response Maximum Likelyhood decoding you can > write and write and write and you will have no idea if it works or > not. Bad sector forwarding is another issue in this area. > > There are commercial companies who have specialized in recovering > deleted data from trackfringes. Still, you could just add a few hundred rewrites with random data. This would decrease probability that the key can be recovered, just as the crypto techniques used in GBDE increase the safety of the data (comparing to CGD, for instance), but never guarantee it. Also, one may even change (if needed) the way GBDE keeps masterkey, salt, etc in memory: avoiding keeping this data at one place in RAM for a long time will practically ruin the hopes to recover anything useful from deenergized RAM. Timestamp: 0x422CABCF [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 22:46:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04EF116A4D1; Mon, 7 Mar 2005 22:46:24 +0000 (GMT) Received: from kuldipmanak.chamkila.org (node-40240ed2.sjc.onnet.us.uu.net [64.36.14.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F28243D54; Mon, 7 Mar 2005 22:46:23 +0000 (GMT) (envelope-from aman@chamkila.org) Received: from mail.chamkila.org (localhost.localdomain [127.0.0.1]) j27Mk4Bg029276; Mon, 7 Mar 2005 14:46:04 -0800 Received: from 69.36.228.194 (proxying for 192.168.96.7) (SquirrelMail authenticated user aman); by mail.chamkila.org with HTTP; Mon, 7 Mar 2005 14:46:04 -0800 (PST) Message-ID: <34148.69.36.228.194.1110235564.squirrel@69.36.228.194> In-Reply-To: <421E604F.3080305@samsco.org> References: <20050119103214.A27409@pooker.samsco.org> <37799.69.36.228.194.1109286815.squirrel@69.36.228.194> <421E604F.3080305@samsco.org> Date: Mon, 7 Mar 2005 14:46:04 -0800 (PST) From: "Amandeep Pannu" To: freebsd-hackers@freebsd.org, "Scott Long" User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal cc: Amandeep Pannu cc: Scott Long Subject: Re: freebsd problem: What SCSI RAID controller compatible with 5.3-Release X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 22:46:24 -0000 Hi Scott, I am encountering these errors wiht FreeBSD 5.3-REL-p5 Any ideas what is going on. ahd0: port 0x4000-0x40ff,0x4400-0x44ff mem 0xfc300000-0xfc301fff irq 28 at device 2.0 on pci3 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs ahd1: port 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 29 at device 2.1 on pci3 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs (probe1:ahd0:0:1:0): No or incomplete CDB sent to device. (probe1:ahd0:0:1:0): Protocol violation in Message-in phase. Attempting to abort. (probe1:ahd0:0:1:0): Abort Message Sent (probe1:ahd0:0:1:0): SCB 14 - Abort Tag Completed. found == 0x1 ahd0: Invalid Sequencer interrupt occurred. >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x23b Mode 0x0 Card was paused INTSTAT[0x0] SELOID[0x1] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x6]:(INTMASK1|INTMASK2) SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x3] KERNEL_QFREEZE_COUNT[0x3] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0x9 NEXTSCB 0xff80 qinstart = 39 qinfifonext = 40 QINFIFO: 0xe WAITING_TID_QUEUES: Pending list: 14 FIFO_USE[0x0] SCB_CONTROL[0x48]:(STATUS_RCVD|DISCENB) SCB_SCSIID[0x17] Total 1 Kernel Free SCB list: 9 15 1 2 3 4 5 6 7 8 10 11 12 13 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xf SEQIMODE[0x3f]: (ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0x9 SEQIMODE[0x3f]: (ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x8 0x0 0x0 0xf 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd0: REG0 == 0x8060, SINDEX = 0x10e, DINDEX = 0x104 ahd0: SCBPTR == 0xf, SCB_NEXT == 0xff80, SCB_NEXT2 == 0xff33 CDB 12 20 0 80 88 86 STACK: 0x236 0x2 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> ses0 at ahd0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 The system is running 5.3-REL-p5 with a custom kernel. I have also tried GENERIC with the same results. the drives da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) ./diskinfo -v /dev/da0s1a /dev/da0s1a 512 # sectorsize 28311552000 # mediasize in bytes (26G) 55296000 # mediasize in sectors 3442 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Thanks in advance Aman From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 23:06:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8806916A4CE for ; Mon, 7 Mar 2005 23:06:31 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DE6743D4C for ; Mon, 7 Mar 2005 23:06:31 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j273BPoH085386; Sun, 6 Mar 2005 19:11:27 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j273BJ2d085385; Sun, 6 Mar 2005 19:11:19 -0800 (PST) (envelope-from www) Date: Sun, 6 Mar 2005 19:11:19 -0800 (PST) Message-Id: <200503070311.j273BJ2d085385@marlena.vvi.at> To: dan@geek.com.au From: "ALeine" cc: freebsd-hackers@FreeBSD.ORG cc: phk@phk.freebsd.dk cc: tech-security@NetBSD.ORG Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 23:06:31 -0000 dan@geek.com.au wrote: > On Mon, Mar 07, 2005 at 09:43:13AM -0700, soralx@cydem.org wrote: > > > > > I also believe that it would be beneficial to implement regular rewriting > > > of randomly picked lock sector(s) at random times during a user specified > > > interval (up to x rewrites within n seconds) in order to further obscure > > > the write pattern and provide additional protection for lock sectors. > > > > I agree. > > I don't. Hiding the lock sector is pointless for hot disk attacks. A > malicious SAN administrator (and other intermediaries, if transport > encryption is not used) can identify the lock sector trivially, > because gbde decrypts its location and tells you: it goes straight > there on startup. The idea I proposed is not meant to address the protection of hot disks, it is mainly meant to address the protection of lock sectors on cold disks that can be accessed at regular intervals for differential analysis. The improved hot disk protection in terms of obscuring write patterns as a result of this mechanism is just a beneficial side-effect and not the main goal. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 07:06:21 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D80716A4CE; Tue, 8 Mar 2005 07:06:21 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C066C43D4C; Tue, 8 Mar 2005 07:06:20 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1D8YnL-000PnZ-9a; Tue, 08 Mar 2005 09:06:19 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: hackers@freebsd.org In-reply-to: Your message of Fri, 25 Feb 2005 12:09:44 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Mar 2005 09:06:19 +0200 From: Danny Braniss Message-ID: cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 07:06:21 -0000 well, i guess all is ok, since im not getting much feedback :-) anyways, this is my new problem: o- the target accepts the login, but does not supply a valid device, usually because some admin. problem. I would like to be able to report the problem to the initiator and I need some clues. The cam will, if successful create /dev/da*, on failure nothing, so Q: how can this be found out without getting into the actual SCSI transactions? thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 7 21:17:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62FFB16A4CE for ; Mon, 7 Mar 2005 21:17:50 +0000 (GMT) Received: from bcd.geek.com.au (geek.com.au [203.17.37.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E078543D31 for ; Mon, 7 Mar 2005 21:17:48 +0000 (GMT) (envelope-from dan@geek.com.au) Received: by bcd.geek.com.au (Postfix, from userid 106) id ED79C49FA8; Tue, 8 Mar 2005 08:17:43 +1100 (EST) Date: Tue, 8 Mar 2005 08:17:43 +1100 From: Daniel Carosone To: soralx@cydem.org Message-ID: <20050307211743.GD20827@bcd.geek.com.au> Mail-Followup-To: soralx@cydem.org, freebsd-hackers@FreeBSD.ORG, tech-security@NetBSD.ORG, phk@phk.freebsd.dk, aleine@austrosearch.net References: <200503052027.j25KRmAF055472@marlena.vvi.at> <200503070940.49393.soralx@cydem.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <200503070940.49393.soralx@cydem.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 08 Mar 2005 13:06:42 +0000 cc: aleine@austrosearch.net cc: freebsd-hackers@FreeBSD.ORG cc: phk@phk.freebsd.dk cc: tech-security@NetBSD.ORG Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 21:17:50 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2005 at 09:43:13AM -0700, soralx@cydem.org wrote: >=20 > > I also believe that it would be beneficial to implement regular rewriti= ng > > of randomly picked lock sector(s) at random times during a user specifi= ed > > interval (up to x rewrites within n seconds) in order to further obscure > > the write pattern and provide additional protection for lock sectors. >=20 > I agree.=20 I don't. Hiding the lock sector is pointless for hot disk attacks. A malicious SAN administrator (and other intermediaries, if transport encryption is not used) can identify the lock sector trivially, because gbde decrypts its location and tells you: it goes straight there on startup. -- Dan. --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (NetBSD) iD8DBQFCLMT3EAVxvV4N66cRAjwdAJ0YIII6Wru0sABfMfvTFlwUCqtPuQCfSKMH s4GFYA0kk/bKutoV5VCVCho= =Vbqw -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 03:11:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A09E416A4CE for ; Tue, 8 Mar 2005 03:11:16 +0000 (GMT) Received: from web41314.mail.yahoo.com (web41314.mail.yahoo.com [66.218.93.63]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E35B43D55 for ; Tue, 8 Mar 2005 03:11:16 +0000 (GMT) (envelope-from ron_chen_123@yahoo.com) Received: (qmail 42243 invoked by uid 60001); 8 Mar 2005 03:11:16 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=XXYmwARp4HHX26xjqeZlAI4KTHqxQVAmUUfpvIwka/ykXJZqHRXKq0f5xG/DMsmnWw/ZolAWmC+6ayLCRgNzVY8xcBptZ/ptf2o8kPYWmK/79SzVl7hsfjCWdNwt+4vZ9WKoFx4hwqTpKfomMkatXQt9tjtAF3YXtKXEMqwDRA0= ; Message-ID: <20050308031115.42240.qmail@web41314.mail.yahoo.com> Received: from [199.246.40.54] by web41314.mail.yahoo.com via HTTP; Mon, 07 Mar 2005 19:11:15 PST Date: Mon, 7 Mar 2005 19:11:15 -0800 (PST) From: Ron Chen To: freebsd-cluster@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 08 Mar 2005 13:06:42 +0000 Subject: Failed to compile Gridengine 6.0u3 on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 03:11:16 -0000 I just got access to a FreeBSD 5.3 box, and I find that Gridengine (SGE) fails to compile. (SGE 5.3p6 was OK on FreeBSD 4.x/5.x) I find that it is caused by pthread_t is undefined. For Linux, "sys/types.h" includes "bits/pthreadtypes.h", and thus it's OK - and other OSes are similar too. So I am wondering if it is a bug in FreeBSD, or if Gridengine really needs to include pthread.h to get pthread_t. BTW, for people interested, Gridengine is an opensource batch/cluster scheduler. For more info: http://gridengine.sunsource.net -Ron __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 13:47:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDF2F16A4CE; Tue, 8 Mar 2005 13:47:17 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAFC043D3F; Tue, 8 Mar 2005 13:47:16 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j28Dl4Rj081362; Tue, 8 Mar 2005 07:47:04 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <422DACD4.9030105@centtech.com> Date: Tue, 08 Mar 2005 07:47:00 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 13:47:18 -0000 Danny Braniss wrote: > well, i guess all is ok, since im not getting much feedback :-) > anyways, this is my new problem: > o- the target accepts the login, but does not supply a valid device, usually > because some admin. problem. I would like to be able to report the problem > to the initiator and I need some clues. The cam will, if successful > create /dev/da*, on failure nothing, so Q: how can this be found out > without getting into the actual SCSI transactions? Is there a target mode implementation of this for FreeBSD yet? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 14:04:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90C0A16A4CE; Tue, 8 Mar 2005 14:04:32 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A01D43D2D; Tue, 8 Mar 2005 14:04:32 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1D8fK3-000CkV-1n; Tue, 08 Mar 2005 16:04:31 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Eric Anderson In-Reply-To: Message from Eric Anderson of "Tue, 08 Mar 2005 07:47:00 CST." <422DACD4.9030105@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Mar 2005 16:04:30 +0200 From: Danny Braniss Message-ID: cc: hackers@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 14:04:32 -0000 > Danny Braniss wrote: > > well, i guess all is ok, since im not getting much feedback :-) > > anyways, this is my new problem: > > o- the target accepts the login, but does not supply a valid device, usually > > because some admin. problem. I would like to be able to report the problem > > to the initiator and I need some clues. The cam will, if successful > > create /dev/da*, on failure nothing, so Q: how can this be found out > > without getting into the actual SCSI transactions? > > > Is there a target mode implementation of this for FreeBSD yet? > speakin for myself, at the moment im trying to get the initiator working, and up to speed, after that i might try and tackle the target, but though there is alot of symmetry, there is much more administrativia involved. danny From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 14:06:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17D9116A4CE for ; Tue, 8 Mar 2005 14:06:00 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6A1843D48 for ; Tue, 8 Mar 2005 14:05:59 +0000 (GMT) (envelope-from ravikrish@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1446702wri for ; Tue, 08 Mar 2005 06:05:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=oCKm42uYXP9XG6kmcQPSkfLIgD7JdedXtC2T+zTY+telb+Ej7ItZBoyijbhhRrL4TUUnve7P4v/iVPSdKh0RsgfXB1Qi+RLVcAWTzopAbPl+yD9Yzr2k8hQa278sXUXfBVVoAI//lr5wTYyCR0KAzBEkD4Cj8YS6dxfombJoxHA= Received: by 10.54.34.54 with SMTP id h54mr59008wrh; Tue, 08 Mar 2005 06:05:58 -0800 (PST) Received: by 10.54.6.48 with HTTP; Tue, 8 Mar 2005 06:05:58 -0800 (PST) Message-ID: <6669fd8605030806056b53307a@mail.gmail.com> Date: Tue, 8 Mar 2005 19:35:58 +0530 From: Ravi Krishna To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: using segmentation to manage memory in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ravi Krishna List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 14:06:00 -0000 Hi all! I would like to know if FreeBSD allows one to use segmentation on x86 to reduce the penalty of context switches. (please read on for details) Virtual memory on x86 can be managed by either segmentation or by paging. when using paging a context switch from one process to other all the TLB mappings stored in TLB cache are flushed, this makes context the switch expensive (we will have lots of TLB misses). There are situations when individual processes donot have large memory requirements . Some processors have TLB tagging, so OS doesnot flush all the TLB entries when a context switch happens, only selective ones are flushed. Unfortunatly Intex x86 does not have TLB tagging available. The way to implement something similar on x86 is using segmentation. say I have four modules A, B, C, D each needing 100MB address. I can give each of these a 100MB segment. Assuming TLB cache is large enough to store TLB mappings for all of these four, to context switch (say frm A to B) I can just switch the segment, by setting segmentation registers. These there will be no TLB flush. When we come back frm B to A again we switch the segment. Now again to TLB flush will happen and A will be able to use the TLB cache entries for its segment. This becomes more attractive for 64 bit systems. My question is that is this functionality available on FreeBSD in any way? Ravi From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 14:07:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31B5816A4CE; Tue, 8 Mar 2005 14:07:18 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8084E43D48; Tue, 8 Mar 2005 14:07:17 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j28E7ARr015966; Tue, 8 Mar 2005 08:07:10 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <422DB18A.6080802@centtech.com> Date: Tue, 08 Mar 2005 08:07:06 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/755/Mon Mar 7 19:00:18 2005 on mh1.centtech.com X-Virus-Status: Clean cc: hackers@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 14:07:18 -0000 Danny Braniss wrote: >>Danny Braniss wrote: >> >>>well, i guess all is ok, since im not getting much feedback :-) >>>anyways, this is my new problem: >>>o- the target accepts the login, but does not supply a valid device, usually >>> because some admin. problem. I would like to be able to report the problem >>> to the initiator and I need some clues. The cam will, if successful >>> create /dev/da*, on failure nothing, so Q: how can this be found out >>> without getting into the actual SCSI transactions? >> >> >>Is there a target mode implementation of this for FreeBSD yet? >> > > speakin for myself, > at the moment im trying to get the initiator working, and up to speed, after that > i might try and tackle the target, but though there is alot of symmetry, there is > much more administrativia involved. I'd help you test, but I have no iscsi targets to test against :) Eirc -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 14:58:55 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D12616A4CE; Tue, 8 Mar 2005 14:58:55 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7B2943D53; Tue, 8 Mar 2005 14:58:54 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j28Ews4l007021; Tue, 8 Mar 2005 06:58:54 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j28Ewsww007020; Tue, 8 Mar 2005 06:58:54 -0800 Date: Tue, 8 Mar 2005 06:58:54 -0800 From: Brooks Davis To: Ron Chen Message-ID: <20050308145854.GA31278@odin.ac.hmc.edu> References: <20050308031115.42240.qmail@web41314.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20050308031115.42240.qmail@web41314.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-hackers@freebsd.org cc: freebsd-cluster@freebsd.org Subject: Re: Failed to compile Gridengine 6.0u3 on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 14:58:55 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2005 at 07:11:15PM -0800, Ron Chen wrote: > I just got access to a FreeBSD 5.3 box, and I find > that Gridengine (SGE) fails to compile. (SGE 5.3p6 was > OK on FreeBSD 4.x/5.x) >=20 > I find that it is caused by pthread_t is undefined. > For Linux, "sys/types.h" includes > "bits/pthreadtypes.h", and thus it's OK - and other > OSes are similar too. >=20 > So I am wondering if it is a bug in FreeBSD, or if > Gridengine really needs to include pthread.h to get > pthread_t. According to The Open Group Base Specifications Issue 6, this is indeed a bug. There should be no harm in also including pthread.h since that is also required to define pthread_t identicaly to sys/types.h. freebsd-threads is the appropriate place to raise this issue. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCLb2tXY6L6fI4GtQRAkrXAJ979WuUoHZ/HO2Sk68MDVL4OPkudACfVuAM ZspzgvVplT+jQS0EEdUfLdE= =5cJC -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 16:02:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E151116A4DA for ; Tue, 8 Mar 2005 16:02:05 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45B6543D46 for ; Tue, 8 Mar 2005 16:02:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30753 invoked from network); 8 Mar 2005 16:02:05 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Mar 2005 16:02:04 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j28G1mLF030122; Tue, 8 Mar 2005 11:01:58 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org, Ravi Krishna Date: Tue, 8 Mar 2005 10:34:19 -0500 User-Agent: KMail/1.6.2 References: <6669fd8605030806056b53307a@mail.gmail.com> In-Reply-To: <6669fd8605030806056b53307a@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503081034.19696.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: hackers@FreeBSD.org Subject: Re: using segmentation to manage memory in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 16:02:08 -0000 On Tuesday 08 March 2005 09:05 am, Ravi Krishna wrote: > Hi all! > > I would like to know if FreeBSD allows one to use segmentation on x86 > to reduce the penalty of context switches. (please read on for > details) > > Virtual memory on x86 can be managed by either segmentation or by paging. > > when using paging a context switch from one process to other all the > TLB mappings stored in TLB cache are flushed, this makes context the > switch expensive (we will have lots of TLB misses). > There are situations when individual processes donot have large memory > requirements . Some processors have TLB tagging, so OS doesnot flush > all the TLB entries when a context switch happens, only selective ones > are flushed. Unfortunatly Intex x86 does not have TLB tagging > available. Actually, it does. It's called the PG_G bit and is present if the PGE feature is listed in CR4 (which it is for most modern processors, maybe Pentium and later?) > The way to implement something similar on x86 is using segmentation. > say I have four modules > A, B, C, D each needing 100MB address. I can give each of these a > 100MB segment. Assuming TLB cache is large enough to store TLB > mappings for all of these four, to context switch (say frm A to B) I > can just switch the segment, by setting segmentation registers. > These there will be no TLB flush. When we come back frm B to A again > we switch the segment. Now again to TLB flush will happen and A will > be able to use the TLB cache entries for its segment. Segments just provide a base + offset into the virtual address space that is backed by the TLB mappings, so to make this practically useful would be a lot more work than would first appear because your segments have to map virtually contiguous memory. > This becomes more attractive for 64 bit systems. 64-bit x86 (that is, amd64 and Intel 64-bit xeons) doesn't even have segments. > My question is that is this functionality available on FreeBSD in any way? Nope. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 16:02:07 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5F6516A4DD for ; Tue, 8 Mar 2005 16:02:05 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45CCE43D48 for ; Tue, 8 Mar 2005 16:02:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30753 invoked from network); 8 Mar 2005 16:02:05 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Mar 2005 16:02:04 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j28G1mLF030122; Tue, 8 Mar 2005 11:01:58 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org, Ravi Krishna Date: Tue, 8 Mar 2005 10:34:19 -0500 User-Agent: KMail/1.6.2 References: <6669fd8605030806056b53307a@mail.gmail.com> In-Reply-To: <6669fd8605030806056b53307a@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503081034.19696.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: hackers@FreeBSD.org Subject: Re: using segmentation to manage memory in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 16:02:09 -0000 On Tuesday 08 March 2005 09:05 am, Ravi Krishna wrote: > Hi all! > > I would like to know if FreeBSD allows one to use segmentation on x86 > to reduce the penalty of context switches. (please read on for > details) > > Virtual memory on x86 can be managed by either segmentation or by paging. > > when using paging a context switch from one process to other all the > TLB mappings stored in TLB cache are flushed, this makes context the > switch expensive (we will have lots of TLB misses). > There are situations when individual processes donot have large memory > requirements . Some processors have TLB tagging, so OS doesnot flush > all the TLB entries when a context switch happens, only selective ones > are flushed. Unfortunatly Intex x86 does not have TLB tagging > available. Actually, it does. It's called the PG_G bit and is present if the PGE feature is listed in CR4 (which it is for most modern processors, maybe Pentium and later?) > The way to implement something similar on x86 is using segmentation. > say I have four modules > A, B, C, D each needing 100MB address. I can give each of these a > 100MB segment. Assuming TLB cache is large enough to store TLB > mappings for all of these four, to context switch (say frm A to B) I > can just switch the segment, by setting segmentation registers. > These there will be no TLB flush. When we come back frm B to A again > we switch the segment. Now again to TLB flush will happen and A will > be able to use the TLB cache entries for its segment. Segments just provide a base + offset into the virtual address space that is backed by the TLB mappings, so to make this practically useful would be a lot more work than would first appear because your segments have to map virtually contiguous memory. > This becomes more attractive for 64 bit systems. 64-bit x86 (that is, amd64 and Intel 64-bit xeons) doesn't even have segments. > My question is that is this functionality available on FreeBSD in any way? Nope. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 16:20:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CC6316A4CE for ; Tue, 8 Mar 2005 16:20:23 +0000 (GMT) Received: from web52702.mail.yahoo.com (web52702.mail.yahoo.com [206.190.39.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 974DC43D4C for ; Tue, 8 Mar 2005 16:20:22 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 67815 invoked by uid 60001); 8 Mar 2005 16:20:21 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=k7cO1iCoDX+zfVOqjjcH3/O8v/NwEcg9RpyD/FaeRM0ecPOqHAaWoN5Y6ZbLYRw5ngcGpfBFqcXrPcESO1dXPFlb+KcP1iyTUAlom5VdpwTW6BnwNEGR1IUYQeqRODG9ETTbvfdoi4GQpavLKUx6RWatOEPTW1Jz9lsW2T3twoY= ; Message-ID: <20050308162021.67813.qmail@web52702.mail.yahoo.com> Received: from [202.91.78.244] by web52702.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 08:20:21 PST Date: Tue, 8 Mar 2005 08:20:21 -0800 (PST) From: "Kamal R. Prasad" To: John Baldwin In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: hackers@freebsd.org Subject: Re: using segmentation to manage memory in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 16:20:23 -0000 --- John Baldwin wrote: > On Tuesday 08 March 2005 09:05 am, Ravi Krishna > wrote: > > Hi all! > > [snip] > > Segments just provide a base + offset into the > virtual address space that is > backed by the TLB mappings, so to make this > practically useful would be a lot > more work than would first appear because your > segments have to map virtually > contiguous memory. > If I had a processor with no MMU, but only memory protection and a segment register, can I port freebsd onto that architecture? I mean, use the segment register to provide for non-conflicting process spaces. thanks -kamal ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 17:51:27 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A65416A4CE for ; Tue, 8 Mar 2005 17:51:27 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB05043D66 for ; Tue, 8 Mar 2005 17:51:26 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9285 invoked from network); 8 Mar 2005 17:51:26 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Mar 2005 17:51:25 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j28HpKHc030806; Tue, 8 Mar 2005 12:51:21 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org, kamalp@acm.org Date: Tue, 8 Mar 2005 11:28:34 -0500 User-Agent: KMail/1.6.2 References: <20050308162021.67813.qmail@web52702.mail.yahoo.com> In-Reply-To: <20050308162021.67813.qmail@web52702.mail.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503081128.34407.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: hackers@FreeBSD.org Subject: Re: using segmentation to manage memory in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 17:51:27 -0000 On Tuesday 08 March 2005 11:20 am, Kamal R. Prasad wrote: > --- John Baldwin wrote: > > On Tuesday 08 March 2005 09:05 am, Ravi Krishna > > > > wrote: > > > Hi all! > > [snip] > > > Segments just provide a base + offset into the > > virtual address space that is > > backed by the TLB mappings, so to make this > > practically useful would be a lot > > more work than would first appear because your > > segments have to map virtually > > contiguous memory. > > If I had a processor with no MMU, but only memory > protection and a segment register, can I port freebsd > onto that architecture? I mean, use the segment > register to provide for non-conflicting process > spaces. Well, it is theoretically possible, yes, but practically speaking I'd think it would be a lot of work. The entire vm system assumes paging. If you had a way of emulating some rather large pages using segmentation then perhaps you could do that. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 17:51:27 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC5616A4CF for ; Tue, 8 Mar 2005 17:51:27 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAEE543D64 for ; Tue, 8 Mar 2005 17:51:26 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9285 invoked from network); 8 Mar 2005 17:51:26 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Mar 2005 17:51:25 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j28HpKHc030806; Tue, 8 Mar 2005 12:51:21 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org, kamalp@acm.org Date: Tue, 8 Mar 2005 11:28:34 -0500 User-Agent: KMail/1.6.2 References: <20050308162021.67813.qmail@web52702.mail.yahoo.com> In-Reply-To: <20050308162021.67813.qmail@web52702.mail.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503081128.34407.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: hackers@FreeBSD.org Subject: Re: using segmentation to manage memory in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 17:51:27 -0000 On Tuesday 08 March 2005 11:20 am, Kamal R. Prasad wrote: > --- John Baldwin wrote: > > On Tuesday 08 March 2005 09:05 am, Ravi Krishna > > > > wrote: > > > Hi all! > > [snip] > > > Segments just provide a base + offset into the > > virtual address space that is > > backed by the TLB mappings, so to make this > > practically useful would be a lot > > more work than would first appear because your > > segments have to map virtually > > contiguous memory. > > If I had a processor with no MMU, but only memory > protection and a segment register, can I port freebsd > onto that architecture? I mean, use the segment > register to provide for non-conflicting process > spaces. Well, it is theoretically possible, yes, but practically speaking I'd think it would be a lot of work. The entire vm system assumes paging. If you had a way of emulating some rather large pages using segmentation then perhaps you could do that. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 20:03:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2981916A4CE for ; Tue, 8 Mar 2005 20:03:08 +0000 (GMT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA2B843D3F for ; Tue, 8 Mar 2005 20:03:06 +0000 (GMT) (envelope-from Vijay.Singh@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])j28K3QA10020 for ; Tue, 8 Mar 2005 22:03:26 +0200 (EET) X-Scanned: Tue, 8 Mar 2005 22:02:55 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j28K2tIu032503 for ; Tue, 8 Mar 2005 22:02:55 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00MVZlU9; Tue, 08 Mar 2005 22:02:55 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122])j28K2sU07962 for ; Tue, 8 Mar 2005 22:02:54 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 14:02:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2005 12:01:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: partial memory dump Thread-Index: AcUkGZhGyNt9jPrvSNePonOXAfmAdw== From: To: X-OriginalArrivalTime: 08 Mar 2005 20:02:53.0905 (UTC) FILETIME=[D065EC10:01C52419] Subject: partial memory dump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 20:03:08 -0000 Hello all. I am trying to allow a FreeBSD based kernel to crash dump = even if configured swap is not enough to fill entire physical memory. = This is because there could be 2G RAM on the system. I assume that most = pages would not be mapped.=20 The algorithm to do this is to have a bitmask, with bits set for pages: = from 0 to Maxmem, and then adding pages from USRSTACK to = vm_map_max(kmem_map). This is done in scsi_da.c, dadump() routine. I am = able to get the dump, and after savecore collects it from swap I get the = kernel and core files. However I am not able to get the stack trace.=20 Anything in the design (pages) that I might have missed? nexthop[admin]# gdb -k kernel.2 vmcore.2 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for = details. GDB 4.16 (i386-unknown-freebsd),=20 Copyright 1996 Free Software Foundation, Inc...(no debugging symbols = found)... IdlePTD 69f000 current pcb at 4dd794 panic: page fault #0 0xf6371ade in boot (cannot read proc at 0xca6c0400 ) (kgdb) bt #0 0xf6371ade in boot (cannot read proc at 0xca6c0400 ) cannot read proc at 0xca6c0400 br, vijay From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 21:39:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8F1716A4F3 for ; Tue, 8 Mar 2005 21:39:39 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 267F543D1D for ; Tue, 8 Mar 2005 21:39:39 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j28LdbXY033072; Tue, 8 Mar 2005 15:39:37 -0600 (CST) (envelope-from dan) Date: Tue, 8 Mar 2005 15:39:37 -0600 From: Dan Nelson To: Vijay.Singh@nokia.com Message-ID: <20050308213937.GF37452@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org Subject: Re: partial memory dump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 21:39:39 -0000 In the last episode (Mar 08), Vijay.Singh@nokia.com said: > Hello all. I am trying to allow a FreeBSD based kernel to crash dump > even if configured swap is not enough to fill entire physical memory. > This is because there could be 2G RAM on the system. I assume that > most pages would not be mapped. > > The algorithm to do this is to have a bitmask, with bits set for > pages: from 0 to Maxmem, and then adding pages from USRSTACK to > vm_map_max(kmem_map). This is done in scsi_da.c, dadump() routine. I > am able to get the dump, and after savecore collects it from swap I > get the kernel and core files. However I am not able to get the stack > trace. I think you also need to write that bitmap to disk so that savecore can read it and put the data blocks in the right place in the vmcore file. You want to end up a with a sparse file, with blank spots every place dadump skipped a block. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 21:50:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C396F16A4CE for ; Tue, 8 Mar 2005 21:50:38 +0000 (GMT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D0343D54 for ; Tue, 8 Mar 2005 21:50:37 +0000 (GMT) (envelope-from Vijay.Singh@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])j28LoZU08540; Tue, 8 Mar 2005 23:50:35 +0200 (EET) X-Scanned: Tue, 8 Mar 2005 23:49:31 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j28LnVoK009786; Tue, 8 Mar 2005 23:49:31 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00sbrI5e; Tue, 08 Mar 2005 23:49:30 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121])j28LnTM09006; Tue, 8 Mar 2005 23:49:29 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 15:49:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2005 13:49:24 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: partial memory dump Thread-Index: AcUkJ4pDeXk3I7MfSYm/gGtIKoQ9tgAAD/Eg From: To: X-OriginalArrivalTime: 08 Mar 2005 21:49:25.0384 (UTC) FILETIME=[B2043880:01C52428] cc: freebsd-hackers@freebsd.org Subject: RE: partial memory dump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 21:50:38 -0000 Hi, thanks for the quick reply. I do indeed write the bitmap, which is a = part of the sysdump_hdr structure to the disk. The disk routine does not = currently report that it had to miss any block. Here is what I get from = dadump(). dumpsys() in machdep.c dumping to dev 20401, offset 0 dadump() dodump: 1 USRSTACK: 0xbfbfc000 to 0xe6fa5000 Maxmem: 524288, secsize: 512 dumplo: 0, num: 84872, size: 2097152 next block to write: 90640 @ 8 blocks/req Dumping bitmap at addr e6fa5000 to sec 16210, 88 sectors next block to write: 90776 @ 8 blocks/req Dumping 0x2960 pages of memory to sec 0x16298, 0x14b00 sectors This version of dadump() does not implement write combining yet. Do you = think savecore is not able to find the data blocks correctly in the = swap? br vijay -----Original Message----- From: ext Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Tuesday, March 08, 2005 1:40 PM To: Singh Vijay (Nokia-NET/MtView) Cc: freebsd-hackers@freebsd.org Subject: Re: partial memory dump In the last episode (Mar 08), Vijay.Singh@nokia.com said: > Hello all. I am trying to allow a FreeBSD based kernel to crash dump > even if configured swap is not enough to fill entire physical memory. > This is because there could be 2G RAM on the system. I assume that > most pages would not be mapped. >=20 > The algorithm to do this is to have a bitmask, with bits set for > pages: from 0 to Maxmem, and then adding pages from USRSTACK to > vm_map_max(kmem_map). This is done in scsi_da.c, dadump() routine. I > am able to get the dump, and after savecore collects it from swap I > get the kernel and core files. However I am not able to get the stack > trace. I think you also need to write that bitmap to disk so that savecore can read it and put the data blocks in the right place in the vmcore file.=20 You want to end up a with a sparse file, with blank spots every place dadump skipped a block. --=20 Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 22:04:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6D1716A4CE for ; Tue, 8 Mar 2005 22:04:52 +0000 (GMT) Received: from pony2pub.arc.nasa.gov (pony2pub.arc.nasa.gov [128.102.31.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73BF743D2D for ; Tue, 8 Mar 2005 22:04:52 +0000 (GMT) (envelope-from jtoung@arc.nasa.gov) Received: from mrcrab.nas.nasa.gov ([129.99.139.47] verified) by pony2pub.arc.nasa.gov (CommuniGate Pro SMTP 4.2.6) with ESMTP id 17518966 for freebsd-hackers@freebsd.org; Tue, 08 Mar 2005 14:04:49 -0800 From: Jerry Toung To: hackers Date: Tue, 8 Mar 2005 14:04:39 -0800 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503081404.39320.jtoung@arc.nasa.gov> Subject: send data to serial port from kernel code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jtoung@arc.nasa.gov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 22:04:52 -0000 Good afternoon list, I am looking for a way to write data to the serial interface (/dev/cuaa0) from a kernel module and also read /dev/ttyd0 still from that same kernel module. Any pointers to doing that will be great. I want on exchange IP traffic from FreeBSD to another host with different OS via serial cable (null modem). So instead of making a call the NIC driver, I want to use the serial port as may physical layer. Any other ideas for doing this is welcome as well. I know the basics of serial programming from a regular C application: #include fd = open("/dev/cuaa0", O_RDWR|O_NDELAY) tcsetattr and tcgetattr etc etc. but that's not what I am looking for. Thank you. Jerry From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 22:08:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AD2216A4CE for ; Tue, 8 Mar 2005 22:08:13 +0000 (GMT) Received: from md2.swissinfo.org (md2.swissinfo.org [146.159.4.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id A37B743D58 for ; Tue, 8 Mar 2005 22:08:10 +0000 (GMT) (envelope-from sebastien.b@swissinfo.org) Received: from mail.swissinfo.org ([194.6.181.33]) by md2.swissinfo.org (phad2.swissinfo.org [146.159.6.10]) (MDaemon.PRO.v7.2.1.R) with ESMTP id 11-md50000294068.msg for ; Tue, 08 Mar 2005 23:08:01 +0100 Received: from [10.0.1.1] (82.231.254.101) by mail.swissinfo.org (7.0.020) (authenticated as sebastien.b) id 4153942002775114 for freebsd-hackers@freebsd.org; Tue, 8 Mar 2005 23:07:56 +0100 From: Sebastien B To: freebsd-hackers@freebsd.org Date: Tue, 8 Mar 2005 23:11:11 +0100 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200503082311.12538.sebastien.b@swissinfo.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Processed: phad2.swissinfo.org, Tue, 08 Mar 2005 23:08:01 +0100 (not processed: spam filter disabled) X-MDRemoteIP: 194.6.181.33 X-Return-Path: sebastien.b@swissinfo.org X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: phad2.swissinfo.org, Tue, 08 Mar 2005 23:08:04 +0100 Subject: ieee80211_input() problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 22:08:13 -0000 Hello, I'm in real trouble with that function :( I have the following code, "frame" is a char pointer to data corresponding to the 802.11 frame and "frame_size" is its length in bytes : if(ic->ic_opmode != IEEE80211_M_STA) { struct ieee80211_frame_min *wh = (struct ieee80211_frame_min *)frame; //data_head; ni = ieee80211_find_node(ic, wh->i_addr2); if(ni == NULL) ni = ieee80211_ref_node(ic->ic_bss); } else ni = ieee80211_ref_node(ic->ic_bss); /* Put the data into an mbuf and pass it to the upper layers */ if(frame_size > MCLBYTES) { p54u_err("Frame too large for mbuf cluster"); return; } MGETHDR(buf, M_DONTWAIT, MT_DATA); if(buf == NULL) { p54u_err("mbuf allocation failed"); return; } if(frame_size > MHLEN) { p54u_dbg("allocating mbuf cluster"); MCLGET(buf, M_DONTWAIT); if((buf->m_flags & M_EXT) == 0) { p54u_err("mbuf cluster allocation failed"); m_freem(buf); return; } } buffer = mtod(buf, char *); memcpy(buffer, frame, frame_size); buf->m_pkthdr.rcvif = &sc->sc_if; buf->m_pkthdr.len = buf->m_len = frame_size; ieee80211_input(&sc->sc_if, buf, ni, data_head->signal_strength, le32toh(data_head->timestamp)); /* * Reclaim node reference. */ if (ni == ic->ic_bss) ieee80211_unref_node(&ni); else ieee80211_free_node(ic, ni); With this, the kernel panics every time a frame is received :( The kernel messages are : Fatal trap 12: page fault while in kernel mode fault virtual address = 0x23 fault code = supervisor read, page not present instruction pointer = 0x8:0xc07c3d82 stack pointer = 0x10:0xd4cf9c20 frame pointer = 0x10:0xd4cf9c60 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 493 (swi7: int_ack++) It suggests that software is attempting to read from an invalid memory location. - I tried commenting out ieee80211_input. No more crashes, but the function's useless... - In case there was not enough space in mbuf (thus ieee80211_input() would try to access memory which doesn't belong to us), I tried reading frame_size bytes from the adress pointed to by "buffer". No crash. Moreover, the mbuf data seems consistent, I can see the ESSID in it (anyway I think that ieee80211_input() shouldn't crash because of an unconsistent frame ; otherwise someone could crash all computers around by sending forged 802.11 frames...) - I tried with and without referencing ic->ic_bss. No effect. - Making frame_size deliberately too small before the call to ieee80211_input() makes the kernel not crash. So ieee80211_input() seems to ignore the packet in case it's too small, it seems to read correctly the size field (I tried 10 bytes). - The data_head->signal_strength and data_head->timestamp dereferencings are not responsible for the kernel panic, and they return the correct data. I hope someone can help, I just can't figure out what's going wrong after hours of debugging, and constantly rebooting is really tedious. Thanks, Sebastien From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 22:09:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A9EF16A4CE for ; Tue, 8 Mar 2005 22:09:46 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B5C943D58 for ; Tue, 8 Mar 2005 22:09:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j28M9jTo089420; Tue, 8 Mar 2005 16:09:45 -0600 (CST) (envelope-from dan) Date: Tue, 8 Mar 2005 16:09:45 -0600 From: Dan Nelson To: Vijay.Singh@nokia.com Message-ID: <20050308220944.GG37452@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org Subject: Re: partial memory dump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 22:09:46 -0000 In the last episode (Mar 08), Vijay.Singh@nokia.com said: > Hi, thanks for the quick reply. I do indeed write the bitmap, which > is a part of the sysdump_hdr structure to the disk. The disk routine > does not currently report that it had to miss any block. Here is what > I get from dadump(). > > dumpsys() in machdep.c > dumping to dev 20401, offset 0 > > dadump() > dodump: 1 > USRSTACK: 0xbfbfc000 to 0xe6fa5000 > Maxmem: 524288, secsize: 512 > dumplo: 0, num: 84872, size: 2097152 > next block to write: 90640 @ 8 blocks/req > Dumping bitmap at addr e6fa5000 to sec 16210, 88 sectors > next block to write: 90776 @ 8 blocks/req > Dumping 0x2960 pages of memory to sec 0x16298, 0x14b00 sectors > > This version of dadump() does not implement write combining yet. Do > you think savecore is not able to find the data blocks correctly in > the swap? No, my worry is that the file savecore is writing is not layed out the way that gdb expects it. gdb is looking for a vmcore the size of your physical memory, where (for example) address 0xe6fa5000 in the system at the time of the crash is at file offset 0xe6fa5000 in vmcore. savecore needs to read that bitmap, and make sure it fseek()'s the output file pointer to the correct location when it writes its blocks. If you're already doing this, then I've exhausted my limited coredump debugging abilities... I also think you should be modifying /sys/i386/i386/dump_machdep.c instead of scsi_da.c; that would let your changes work with any disk backend. The low-level dadump() function shouldn't really have any knowledge of what it's writing. That's something to fix once you're ready to release you code :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 22:26:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E543916A4CE for ; Tue, 8 Mar 2005 22:26:08 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 46C9143D39 for ; Tue, 8 Mar 2005 22:26:08 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 11261 invoked by uid 89); 8 Mar 2005 22:26:06 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 8 Mar 2005 22:26:06 -0000 Received: (qmail 11226 invoked by uid 89); 8 Mar 2005 22:26:06 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 8 Mar 2005 22:26:06 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j28MQ5w6047275; Tue, 8 Mar 2005 17:26:05 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: jtoung@arc.nasa.gov In-Reply-To: <200503081404.39320.jtoung@arc.nasa.gov> References: <200503081404.39320.jtoung@arc.nasa.gov> Content-Type: text/plain Message-Id: <1110320765.29804.7607.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Mar 2005 17:26:05 -0500 Content-Transfer-Encoding: 7bit cc: hackers Subject: Re: send data to serial port from kernel code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 22:26:09 -0000 On Tue, 2005-03-08 at 17:04, Jerry Toung wrote: > Good afternoon list, > I am looking for a way to write data to the serial interface (/dev/cuaa0) from > a kernel module and also read /dev/ttyd0 still from that same kernel module. > Any pointers to doing that will be great. > > I want on exchange IP traffic from FreeBSD to another host with different OS > via serial cable (null modem). So instead of making a call the NIC driver, I > want to use the serial port as may physical layer. > Any other ideas for doing this is welcome as well. > > I know the basics of serial programming from a regular C application: > > #include > > fd = open("/dev/cuaa0", O_RDWR|O_NDELAY) > tcsetattr and tcgetattr > etc etc. > > > but that's not what I am looking for. > > Thank you. > Jerry What is wrong with just using PPP ? Stephan From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 22:49:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9763316A4CE for ; Tue, 8 Mar 2005 22:49:43 +0000 (GMT) Received: from pony2pub.arc.nasa.gov (pony2pub.arc.nasa.gov [128.102.31.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7551143D41 for ; Tue, 8 Mar 2005 22:49:43 +0000 (GMT) (envelope-from jtoung@arc.nasa.gov) Received: from mrcrab.nas.nasa.gov ([129.99.139.47] verified) by pony2pub.arc.nasa.gov (CommuniGate Pro SMTP 4.2.6) with ESMTP id 17520652; Tue, 08 Mar 2005 14:49:42 -0800 From: Jerry Toung To: Stephan Uphoff Date: Tue, 8 Mar 2005 14:49:32 -0800 User-Agent: KMail/1.5.4 References: <200503081404.39320.jtoung@arc.nasa.gov> <1110320765.29804.7607.camel@palm> In-Reply-To: <1110320765.29804.7607.camel@palm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503081449.32741.jtoung@arc.nasa.gov> cc: hackers Subject: Re: send data to serial port from kernel code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jtoung@arc.nasa.gov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 22:49:43 -0000 Because all my IP traffic is directed to kernel module I wrote. It appends some headers after the IP header and when it's done with the specific processing, the packet can now be sent. At that point I used to make a call to the ethernet output routine (*ifp->if_start)() and all is well. Today I have a new requirement. I need to send those packets to the first serial port from the kernel module. Still looking for inputs. Thank you On Tuesday 08 March 2005 02:26 pm, Stephan Uphoff wrote: > On Tue, 2005-03-08 at 17:04, Jerry Toung wrote: > > Good afternoon list, > > I am looking for a way to write data to the serial interface (/dev/cuaa0) > > from a kernel module and also read /dev/ttyd0 still from that same kernel > > module. Any pointers to doing that will be great. > > > > I want on exchange IP traffic from FreeBSD to another host with different > > OS via serial cable (null modem). So instead of making a call the NIC > > driver, I want to use the serial port as may physical layer. > > Any other ideas for doing this is welcome as well. > > > > I know the basics of serial programming from a regular C application: > > > > #include > > > > fd = open("/dev/cuaa0", O_RDWR|O_NDELAY) > > tcsetattr and tcgetattr > > etc etc. > > > > > > but that's not what I am looking for. > > > > Thank you. > > Jerry > > What is wrong with just using PPP ? > > Stephan -- --------------------------------------------------- Jerry Toung Network Software Engineer, AMTI NASA Ames Research Center mail stop: 258-6 Moffett Field, CA 94035 tel: 650-604-1310 --------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 23:25:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21C0A16A4CE for ; Tue, 8 Mar 2005 23:25:37 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id ABBEE43D55 for ; Tue, 8 Mar 2005 23:25:36 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 4234 invoked by uid 89); 8 Mar 2005 23:25:35 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 8 Mar 2005 23:25:35 -0000 Received: (qmail 4220 invoked by uid 89); 8 Mar 2005 23:25:34 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 8 Mar 2005 23:25:34 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j28NPYw6047666; Tue, 8 Mar 2005 18:25:34 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: jtoung@arc.nasa.gov In-Reply-To: <200503081449.32741.jtoung@arc.nasa.gov> References: <200503081404.39320.jtoung@arc.nasa.gov> <200503081449.32741.jtoung@arc.nasa.gov> Content-Type: text/plain Message-Id: <1110324334.29804.7913.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Mar 2005 18:25:34 -0500 Content-Transfer-Encoding: 7bit cc: hackers Subject: Re: send data to serial port from kernel code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 23:25:37 -0000 On Tue, 2005-03-08 at 17:49, Jerry Toung wrote: > Because all my IP traffic is directed to kernel module I wrote. It appends > some headers after the IP header and when it's done with the specific > processing, the packet can now be sent. > At that point I used to make a call to the ethernet output routine > (*ifp->if_start)() and all is well. > > Today I have a new requirement. I need to send those packets to the first > serial port from the kernel module. > > Still looking for inputs. > Thank you Is it still a legal IP package when you are done with it? Is the framing on the serial protocol specified or can you roll your own? I really would recommend layering/tunneling your protocol on/with PPP to avoid re-inventing the wheel - but if this does not work for you take a look at NG_TTY(4) > On Tuesday 08 March 2005 02:26 pm, Stephan Uphoff wrote: > > On Tue, 2005-03-08 at 17:04, Jerry Toung wrote: > > > Good afternoon list, > > > I am looking for a way to write data to the serial interface (/dev/cuaa0) > > > from a kernel module and also read /dev/ttyd0 still from that same kernel > > > module. Any pointers to doing that will be great. > > > > > > I want on exchange IP traffic from FreeBSD to another host with different > > > OS via serial cable (null modem). So instead of making a call the NIC > > > driver, I want to use the serial port as may physical layer. > > > Any other ideas for doing this is welcome as well. > > > > > > I know the basics of serial programming from a regular C application: > > > > > > #include > > > > > > fd = open("/dev/cuaa0", O_RDWR|O_NDELAY) > > > tcsetattr and tcgetattr > > > etc etc. > > > > > > > > > but that's not what I am looking for. > > > > > > Thank you. > > > Jerry > > > > What is wrong with just using PPP ? > > > > Stephan From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 17:06:49 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AC4816A4CE for ; Tue, 8 Mar 2005 17:06:49 +0000 (GMT) Received: from dutch10.digitalus.nl (dutch10.digitalus.nl [81.173.33.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D3D343D58 for ; Tue, 8 Mar 2005 17:06:48 +0000 (GMT) (envelope-from webmaster@shizukana.net) Received: from www.shizukana.net (localhost.localdomain [127.0.0.1]) by dutch10.digitalus.nl (8.12.10/8.12.10) with ESMTP id j28H6h0g017341 for ; Tue, 8 Mar 2005 18:06:43 +0100 Received: from 84.26.82.135 (SquirrelMail authenticated user webmaster@shizukana.net); by www.shizukana.net with HTTP; Tue, 8 Mar 2005 18:06:43 +0100 (CET) Message-ID: <3864.84.26.82.135.1110301603.squirrel@84.26.82.135> Date: Tue, 8 Mar 2005 18:06:43 +0100 (CET) From: "Webmaster Shizukana.net" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Wed, 09 Mar 2005 12:53:58 +0000 Subject: /boot/loader Invalid Format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 17:06:49 -0000 Can somebody help me? I've got a problem with my bootloader and i dont know how to fix it. If I boot my pc, it stops loading, it says: Invalid Format. FreeBSD/i386-Release 5.3 default: 0:ad(0,a)/kernel boot: and it is in the /boot/loader how can i fix this? is there a disk to boot to prompt, so i can mount the / of my freebsd system and update the /boot/loader file with the one of someone else? and ifso, how can i do this with the mount commands? thanks! Nexohrion From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 19:11:47 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B413516A4CE for ; Tue, 8 Mar 2005 19:11:47 +0000 (GMT) Received: from mail.telnix.com (office.telnix.com [70.58.179.73]) by mx1.FreeBSD.org (Postfix) with SMTP id E6E8843D5D for ; Tue, 8 Mar 2005 19:11:46 +0000 (GMT) (envelope-from sdsmith@telnix.com) Received: (qmail 66941 invoked from network); 8 Mar 2005 19:11:46 -0000 Received: from localhost (HELO mail.telnix.com) (127.0.0.1) by localhost with SMTP; 8 Mar 2005 19:11:46 -0000 Received: from 192.168.10.12 (SquirrelMail authenticated user sdsmith@telnix.com); by mail.telnix.com with HTTP; Tue, 8 Mar 2005 11:11:46 -0800 (PST) Message-ID: <2384.192.168.10.12.1110309106.squirrel@192.168.10.12> In-Reply-To: <20050308031115.42240.qmail@web41314.mail.yahoo.com> References: <20050308031115.42240.qmail@web41314.mail.yahoo.com> Date: Tue, 8 Mar 2005 11:11:46 -0800 (PST) From: "Scott D. Smith" To: "Ron Chen" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Rating: localhost 0/1/N X-Mailman-Approved-At: Wed, 09 Mar 2005 12:53:58 +0000 cc: freebsd-hackers@freebsd.org cc: freebsd-cluster@freebsd.org Subject: Re: Failed to compile Gridengine 6.0u3 on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: sdsmith@telnix.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 19:11:48 -0000 SGE installed flawlessly from ports on my miriad of 5.3 systems, most of which are/were fresh clean installs. Checking what ports does to make it work should answer your question. On Mon, March 7, 2005 7:11 pm, Ron Chen said: > I just got access to a FreeBSD 5.3 box, and I find > that Gridengine (SGE) fails to compile. (SGE 5.3p6 was > OK on FreeBSD 4.x/5.x) > > I find that it is caused by pthread_t is undefined. > For Linux, "sys/types.h" includes > "bits/pthreadtypes.h", and thus it's OK - and other > OSes are similar too. > > So I am wondering if it is a bug in FreeBSD, or if > Gridengine really needs to include pthread.h to get > pthread_t. > > BTW, for people interested, Gridengine is an > opensource batch/cluster scheduler. For more info: > > http://gridengine.sunsource.net > > -Ron ------------------------------------------------ - Oregon Public Communications, Inc. - - www.oregonvoices.org - 1-866-485-3979 - ------------------------------------------------ - Telnix, Inc. - www.telnix.com - 541-485-3979 - ------------------------------------------------ - WE TRANSITION BUSINESS INTO THE FUTURE - ------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 8 21:05:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA0A516A4CE; Tue, 8 Mar 2005 21:05:13 +0000 (GMT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCC2143D54; Tue, 8 Mar 2005 21:05:12 +0000 (GMT) (envelope-from axel@axel.truedestiny.net) Received: from [10.0.10.10] (void-ptr.xs4all.nl [80.126.86.58]) j28L59Vh062142; Tue, 8 Mar 2005 22:05:10 +0100 (CET) (envelope-from axel@axel.truedestiny.net) Message-ID: <422E1384.2080107@axel.truedestiny.net> Date: Tue, 08 Mar 2005 22:05:08 +0100 From: "Axel Scheepers (@home)" User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sdsmith@telnix.com References: <20050308031115.42240.qmail@web41314.mail.yahoo.com> <2384.192.168.10.12.1110309106.squirrel@192.168.10.12> In-Reply-To: <2384.192.168.10.12.1110309106.squirrel@192.168.10.12> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Wed, 09 Mar 2005 12:53:58 +0000 cc: freebsd-hackers@freebsd.org cc: Ron Chen cc: freebsd-cluster@freebsd.org Subject: Re: Failed to compile Gridengine 6.0u3 on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 21:05:13 -0000 Scott D. Smith wrote: >SGE installed flawlessly from ports on my miriad of 5.3 systems, most of >which are/were fresh clean installs. Checking what ports does to make it >work should answer your question. > > > > Ports uses 5.x afaik. I've installed it from ports also. Kind regards, Axel Scheepers From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 9 01:00:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5046E16A4D0 for ; Wed, 9 Mar 2005 01:00:28 +0000 (GMT) Received: from web41302.mail.yahoo.com (web41302.mail.yahoo.com [66.218.93.51]) by mx1.FreeBSD.org (Postfix) with SMTP id 3E3CB43D53 for ; Wed, 9 Mar 2005 01:00:21 +0000 (GMT) (envelope-from ron_chen_123@yahoo.com) Received: (qmail 2680 invoked by uid 60001); 9 Mar 2005 01:00:20 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=nVcwvWJH6vUPACd4udDwcLc/dnS956iIM1MhqCedyV/P218xERIVnMD2+glSDhj65VfRubzODsfvnrY+OPUxDMcyvYmsyI25cZQk41c60do0ZBiaCIEVNYa/gTU08PzSl+YtNbZS5uB+zjOiU6bef9d4rNJk8dHCrdn4k6s6v9g= ; Message-ID: <20050309010020.2678.qmail@web41302.mail.yahoo.com> Received: from [24.42.232.253] by web41302.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 17:00:20 PST Date: Tue, 8 Mar 2005 17:00:20 -0800 (PST) From: Ron Chen To: "Axel Scheepers (@home)" , sdsmith@telnix.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 09 Mar 2005 12:53:58 +0000 cc: freebsd-hackers@freebsd.org cc: freebsd-cluster@freebsd.org Subject: Re: Failed to compile Gridengine 6.0u3 on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 01:00:28 -0000 --- "Axel Scheepers (@home)" wrote: > Ports uses 5.x afaik. I've installed it from ports Well, I know. But we(*) need to make sure that it works well on FreeBSD 5.x before other users tell us that SGE6 breaks on FreeBSD 5.x. BTW, SGE6 uses threads to scale to very large clusters (like several thousand machines). So I see a good match with SGE 6 on FreeBSD 5.x. -Ron (*) actually, I did some initial SGE porting work on FreeBSD, and Brooks cleaned it up and finished it :) > also. > > Kind regards, > Axel Scheepers > > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 9 13:18:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B87E16A4CE for ; Wed, 9 Mar 2005 13:18:39 +0000 (GMT) Received: from mxsf05.cluster1.charter.net (mxsf05.cluster1.charter.net [209.225.28.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBDA343D48 for ; Wed, 9 Mar 2005 13:18:38 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip13.cluster1.charter.net (mxip13a.cluster1.charter.net [209.225.28.143])j29DIbqD007709 for ; Wed, 9 Mar 2005 08:18:37 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip13.cluster1.charter.net with ESMTP; 09 Mar 2005 08:18:37 -0500 X-Ironport-AV: i="3.90,150,1107752400"; d="scan'208"; a="825390304:sNHT12686984" Date: Wed, 9 Mar 2005 08:18:32 -0500 (EST) From: c0ldbyte To: "Webmaster Shizukana.net" In-Reply-To: <3864.84.26.82.135.1110301603.squirrel@84.26.82.135> Message-ID: <20050309081654.J86616@eleanor.us1.wmi.uvac.net> References: <3864.84.26.82.135.1110301603.squirrel@84.26.82.135> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: /boot/loader Invalid Format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 13:18:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 8 Mar 2005, Webmaster Shizukana.net wrote: > Can somebody help me? > > I've got a problem with my bootloader and i dont know how to fix it. > If I boot my pc, it stops loading, it says: > > Invalid Format. > > FreeBSD/i386-Release 5.3 > default: 0:ad(0,a)/kernel > boot: > > and it is in the /boot/loader > how can i fix this? > is there a disk to boot to prompt, so i can mount the / of my freebsd > system and update the /boot/loader file with the one of someone else? > > and ifso, how can i do this with the mount commands? > > thanks! > Nexohrion Yes, more then likely you compiled things or have used the iso image for the wrong architecture. It will help us more for you to specify what image you used to make the CD and or if you have installed it and recompiled your kernel/world etc... etc... etc... Thanks, c0ldbyte. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCLveqsmFQuvffl58RAqPYAJ9NZdt6vEzeTEmvcpD4EEsrqR2OfACglrAc RG+0U1Mt4qqThmEX8mBk1c8= =JBEq -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 9 14:59:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF5EF16A4CE for ; Wed, 9 Mar 2005 14:59:06 +0000 (GMT) Received: from dutch10.digitalus.nl (dutch10.digitalus.nl [81.173.33.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5ADA43D4C for ; Wed, 9 Mar 2005 14:59:05 +0000 (GMT) (envelope-from webmaster@shizukana.net) Received: from www.shizukana.net (localhost.localdomain [127.0.0.1]) j29Ex00g017152; Wed, 9 Mar 2005 15:59:00 +0100 Received: from 84.26.82.135 (SquirrelMail authenticated user webmaster@shizukana.net); by www.shizukana.net with HTTP; Wed, 9 Mar 2005 15:59:01 +0100 (CET) Message-ID: <62739.84.26.82.135.1110380341.squirrel@84.26.82.135> In-Reply-To: <20050309081654.J86616@eleanor.us1.wmi.uvac.net> References: <3864.84.26.82.135.1110301603.squirrel@84.26.82.135> <20050309081654.J86616@eleanor.us1.wmi.uvac.net> Date: Wed, 9 Mar 2005 15:59:01 +0100 (CET) From: "Webmaster Shizukana.net" To: "c0ldbyte" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-hackers@freebsd.org cc: "Webmaster Shizukana.net" Subject: Re: /boot/loader Invalid Format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 14:59:06 -0000 It's resloved, she edit the /boot/loader instead of /boot/loader.conf fix: if someone has freebsd release as you, let him upload it to a site, with the name loader.x then boot your computer with the fixit cd of freebsd (Disk 2) Configure your Network go to shell, then cd /mnt mkdir fixbsd mount /dev/ad0s1 /mnt/fixbsd (if you don't have freebsd installed on the first fixed disk or something else like other partitions then figure out which partition the / mountpoint has.) then cd fixbsd fetch (location where your friend has uploaded his bootloader) cp loader.x loader replace it then your set you can bootup normal. If you have 5.3-RELEASE... my loader is located at http://www.raisingfire.net/freebsd/loader.x (founded this trick out with a friend of mine who messed up her bootloader hehe kinda mistake, can happen to everyone if they are logged in as root) With kind regards, Nexohrion > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 8 Mar 2005, Webmaster Shizukana.net wrote: > >> Can somebody help me? >> >> I've got a problem with my bootloader and i dont know how to fix it. >> If I boot my pc, it stops loading, it says: >> >> Invalid Format. >> >> FreeBSD/i386-Release 5.3 >> default: 0:ad(0,a)/kernel >> boot: >> >> and it is in the /boot/loader >> how can i fix this? >> is there a disk to boot to prompt, so i can mount the / of my freebsd >> system and update the /boot/loader file with the one of someone else? >> >> and ifso, how can i do this with the mount commands? >> >> thanks! >> Nexohrion > > Yes, more then likely you compiled things or have used the iso image > for the wrong architecture. It will help us more for you to specify > what image you used to make the CD and or if you have installed it > and recompiled your kernel/world etc... etc... etc... > > Thanks, c0ldbyte. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (FreeBSD) > Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F > > iD8DBQFCLveqsmFQuvffl58RAqPYAJ9NZdt6vEzeTEmvcpD4EEsrqR2OfACglrAc > RG+0U1Mt4qqThmEX8mBk1c8= > =JBEq > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Wed Mar 9 15:28:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8640F16A597 for ; Wed, 9 Mar 2005 15:28:48 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E0CC43D1F for ; Wed, 9 Mar 2005 15:28:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4613 invoked from network); 9 Mar 2005 15:28:48 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 9 Mar 2005 15:28:47 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j29FSR76043398; Wed, 9 Mar 2005 10:28:39 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Wed, 9 Mar 2005 10:29:46 -0500 User-Agent: KMail/1.6.2 References: <3864.84.26.82.135.1110301603.squirrel@84.26.82.135> <20050309081654.J86616@eleanor.us1.wmi.uvac.net> <62739.84.26.82.135.1110380341.squirrel@84.26.82.135> In-Reply-To: <62739.84.26.82.135.1110380341.squirrel@84.26.82.135> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503091029.46885.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: c0ldbyte cc: "Webmaster Shizukana.net" Subject: Re: /boot/loader Invalid Format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 15:28:48 -0000 On Wednesday 09 March 2005 09:59 am, Webmaster Shizukana.net wrote: > It's resloved, she edit the /boot/loader instead of /boot/loader.conf > > fix: You can also just use /boot/loader.old to boot up and then cp loader.old to loader. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 9 15:30:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACD8E16A4CE; Wed, 9 Mar 2005 15:30:57 +0000 (GMT) Received: from dutch10.digitalus.nl (dutch10.digitalus.nl [81.173.33.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED7DB43D3F; Wed, 9 Mar 2005 15:30:56 +0000 (GMT) (envelope-from webmaster@shizukana.net) Received: from www.shizukana.net (localhost.localdomain [127.0.0.1]) j29FUq0g020832; Wed, 9 Mar 2005 16:30:52 +0100 Received: from 84.26.82.135 (SquirrelMail authenticated user webmaster@shizukana.net); by www.shizukana.net with HTTP; Wed, 9 Mar 2005 16:30:52 +0100 (CET) Message-ID: <54267.84.26.82.135.1110382252.squirrel@84.26.82.135> In-Reply-To: <200503091029.46885.jhb@FreeBSD.org> References: <3864.84.26.82.135.1110301603.squirrel@84.26.82.135> <20050309081654.J86616@eleanor.us1.wmi.uvac.net> <62739.84.26.82.135.1110380341.squirrel@84.26.82.135> <200503091029.46885.jhb@FreeBSD.org> Date: Wed, 9 Mar 2005 16:30:52 +0100 (CET) From: "Webmaster Shizukana.net" To: "John Baldwin" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-hackers@freebsd.org cc: "Webmaster Shizukana.net" Subject: Re: /boot/loader Invalid Format X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 15:30:57 -0000 yeah but there was no loader.old so this is fix if you don't have the loader.old regards, Nexohrion The user " John Baldwin" wrote this strange object...: > On Wednesday 09 March 2005 09:59 am, Webmaster Shizukana.net wrote: >> It's resloved, she edit the /boot/loader instead of /boot/loader.conf >> >> fix: > > You can also just use /boot/loader.old to boot up and then cp loader.old > to > loader. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > _______________________________________________ > 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 Wed Mar 9 21:44:47 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C13816A4CE for ; Wed, 9 Mar 2005 21:44:47 +0000 (GMT) Received: from web50209.mail.yahoo.com (web50209.mail.yahoo.com [206.190.38.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 2CAA843D3F for ; Wed, 9 Mar 2005 21:44:46 +0000 (GMT) (envelope-from nahthan666@yahoo.com) Received: (qmail 99021 invoked by uid 60001); 9 Mar 2005 21:44:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=XmreYetjfXE21BAXpM2KeaJnOEJFWigvlX+Y+ETHywIXBDDrw+YHXcd2FgO9IrEQmBu9+sqQU+zSAknFN5ArFcRyE3zOKfGiI0Z4yduuUEqRRxaO/JgmCUfvSVPhTNBgd6Es4lhwBLI6y4JW/zWw3XXdRtk2/7Q4imAMogr7P3w= ; Message-ID: <20050309214444.99019.qmail@web50209.mail.yahoo.com> Received: from [216.240.27.23] by web50209.mail.yahoo.com via HTTP; Wed, 09 Mar 2005 13:44:44 PST Date: Wed, 9 Mar 2005 13:44:44 -0800 (PST) From: nahthan subramanian To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: FreeBSD on IBM BladeCenter? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 21:44:47 -0000 Hi there, Any success stories out there of getting FreeBSD running on IBM BladeCenter hardware? It's not officially supported. It's designed to run Linux/*doze. Here's a document of my attempts: --------------------------- Hardware Information general: http://www-1.ibm.com/servers/eserver/bladecenter/ chassis: http://tinyurl.com/4gcbw blade: http://tinyurl.com/6js9m HS20 blade machine type: 8843 HS20 blade model number: 11U Chassis model number: 8677-3XU Chassis machine type: 8843 Chassis model number: 11U basic blade config: Dual Intel Xeon 3.0Ghz hyper threading and EM64T support 4096MB memory ---------------- FreeBSD Installation media tried: tried with freebsd 5.3 i386 from floppy & CD tried with freebsd 4.ii i386 from floppy & CD -- tried with BIOS 1.2 on blade. tried with BIOS 1.0 on blade. -- tried with an extrenal USB keyboard connected, and without. -- tried with hyperthreading disabled in BIOS. tried with CPU cache enabled/disabled in BIOS. tried with CPU write back cache enabled/disabled in BIOS. tried with CPU prefetch queue enabled/disabled in BIOS. tried with CPU Execute Disable bit enabled/disabled in BIOS. -- tried with ACPI enabled/disabled from the installation prompt. nothing. Here are the crashes and error messages: ------- FreeBSD 5.3 boot from CD/floppy crash/panic: atapci0: port 0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at drvice 31.1 on pci0 fatal trap 12: page fault while in kernel mode fault virtual address = 0x5 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06200d0 stack pointer = 0x10:0xc1021914 frame pointer = 0x10:0xc1021914 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IPOL=0 current process = 0 (swapper) trap number = 12 panic: page fault uptime: 1s shutting down ACPI stray IRQ 11 Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Keyboard reset did not work, attempting CPU shutdown ------------------------------------------------------------------------------ FreeBSD 5.2.1 booting from CD, hangs on boot: acpi0: on motherboard pcibios: BIOS version 2.10 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 (...hangs here forever... machine completely locks up...) ------------------------------------------------------------------------------ FreeBSD 4.11, booting from CD: Uncompressing ... done BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive C: is disk0 BIOS 629/3275513kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 (root@perseus.cse.buffalo.edu, Fri Jan 21 15:42:07 GMT 2005) Can't work out which disk we're booting from. Guessed BIOS device 0x0 not found by probes, defaulting to disk0: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... can't load 'kernel' can't load 'kernel.old' Type '?' for a list of commands, 'help' for more detailed help. ok ------------- FreeBSD 4.11, booting from floppy: Uncompressing ... done BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive C: is disk0 BIOS 629/3275513kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 (root@perseus.cse.buffalo.edu, Fri Jan 21 15:42:07 GMT 2005) /kernel text=0x289d91 data=0x30170+0x32d04 zf_read: fill error elf_loadexec: archsw.readin failed can't load module '/kernel': input/output error - Hit [Enter] to boot immediately, or any other key for command prompt. booting [kernel]... /kernel text=0x289d91 data=0x30170+0x32d04 zf_read: fill error elf_loadexec: archsw.readin failed can't load 'kernel' can't load 'kernel.old' Type '?' for a list of commands, 'help' for more detailed help. ok ---------------------------- I can't think of much else to try for now. Any clues? Thanks. -Nate --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 00:49:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 19E9216A4CE; Thu, 10 Mar 2005 00:49:19 +0000 (GMT) Date: Thu, 10 Mar 2005 00:49:19 +0000 From: Kris Kennaway To: Mikhail Teterin Message-ID: <20050310004919.GA34206@hub.freebsd.org> References: <200503091838.06322.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503091838.06322.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-fs@FreeBSD.org cc: hackers@FreeBSD.org Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 00:49:19 -0000 On Wed, Mar 09, 2005 at 06:38:06PM -0500, Mikhail Teterin wrote: > Hello! > > The respected manual contain dire warnings, but the Google search suggests, > the situation is not *that* gloomy. > > For example, according to http://kerneltrap.org/node/652 , nullfs was used on > Bento-cluster two years ago in 2003. nullfs seems to work fine, unionfs is very fragile and easily exploded. > Is anybody working on this file-systems? Any plans, rumours? > > What about the `union' option to regular mounts? Is that safe to use? Yes. Kris From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 01:31:58 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D868916A4CE for ; Thu, 10 Mar 2005 01:31:58 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58B2D43D46 for ; Thu, 10 Mar 2005 01:31:58 +0000 (GMT) (envelope-from wbierman@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so333016rnf for ; Wed, 09 Mar 2005 17:31:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=tZDXKy6wMhNuBI1T6VeUPFofVTn/67TRo5PigKyMl1lu1hM/WDSUV9Zbk7bF+RyioY8zhJ3ByjTZpM4ZcS7RKCQX3dWz67yWOc9YfIbUHMAm+PCTbu6UjCZCmukIkCmUn8bJ5J+g3f2RDsU/QRdhh82bipJGsQnAVmeGL8Ym5QE= Received: by 10.38.75.66 with SMTP id x66mr1396038rna; Wed, 09 Mar 2005 17:31:58 -0800 (PST) Received: by 10.38.88.21 with HTTP; Wed, 9 Mar 2005 17:31:58 -0800 (PST) Message-ID: Date: Wed, 9 Mar 2005 15:31:58 -1000 From: William Bierman To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Can someone please help me? Why does init fail to start? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: William Bierman List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 01:31:59 -0000 Hello. I setup the partitions/slices correctly, extracted the correct files to each, and installed the kernel and initialized the boot sector. The kernel loads succesfully but is unable to succesfully hand over control to the init process. I established this by putting print debug statements at the point where the kernel calls init via execve(), and at the start of init. The kernel print statement is shown, however the init statement is not. Any clues? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 02:05:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE50E16A4CE for ; Thu, 10 Mar 2005 02:05:35 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.48.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B9D943D55 for ; Thu, 10 Mar 2005 02:05:35 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.135]) by smtp.ucla.edu (8.13.1/8.13.1) with ESMTP id j2A25ZqH004184 for ; Wed, 9 Mar 2005 18:05:35 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j2A25YB7018245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 Mar 2005 18:05:35 -0800 Message-ID: <001b01c52515$a88c6000$abe243a4@ash> From: "Ashwin Chandra" To: Date: Wed, 9 Mar 2005 18:05:39 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0.18 X-Scanned-By: smtp.ucla.edu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Thread Suspensions?? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 02:05:36 -0000 So does anyone know why the following code in the scheduler causes = normal processes like bash and cron to be suspended as well? I have = printed out all the proc names in this loop (inside the if statements) = and none of them are bash or cron. FOREACH_THREAD_IN_PROC(p, td) { if(p->p_km_switch =3D=3D P_NON_RUN) if( !TD_IS_SUSPENDED(td) ) TD_SET_SUSPENDED(td); =20 else if(p->p_km_switch =3D=3D P_RUN) if(TD_IS_SUSPENDED(td)) TD_CLR_SUSPENDED(td); } From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 02:36:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 879A516A4CE; Thu, 10 Mar 2005 02:36:33 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5EFF43D2F; Thu, 10 Mar 2005 02:36:32 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2A2ZJRM011821; Wed, 9 Mar 2005 21:35:19 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2A2ZJWi011820; Wed, 9 Mar 2005 21:35:19 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 9 Mar 2005 21:35:19 -0500 From: David Schultz To: Mikhail Teterin Message-ID: <20050310023518.GA11712@VARK.MIT.EDU> Mail-Followup-To: Mikhail Teterin , hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG References: <200503091838.06322.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503091838.06322.mi+mx@aldan.algebra.com> cc: freebsd-fs@FreeBSD.ORG cc: hackers@FreeBSD.ORG Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 02:36:33 -0000 On Wed, Mar 09, 2005, Mikhail Teterin wrote: > Hello! > > The respected manual contain dire warnings, but the Google search suggests, > the situation is not *that* gloomy. > > For example, according to http://kerneltrap.org/node/652 , nullfs was used on > Bento-cluster two years ago in 2003. > > Is anybody working on this file-systems? Any plans, rumours? Nullfs works better than unionfs. Unionfs worked well in 4.X. Despite numerous minor bugs such as being unable to cope with FIFOs, several people have reported using it quite successfully on production systems. However, unionfs no longer works quite as well in 5.X or -CURRENT. There are several reasons for this: 1. Nobody seems to have both the time and interest to maintain it. 2. Developers can't be expected to prevent regressions in something that's unsupported. 3. There are a couple of people who always respond to questions about unionfs with comments along the lines of: ``It's broken, so we won't help you. Go away and don't tell us if you find any bugs.'' There's some pretty low-hanging fruit in terms of nits to fix. See the PR database if you're interested in helping, and don't let anyone scare you away. ;-) > What about the `union' option to regular mounts? Is that safe to use? Last I checked, it was very broken, but I'm not sure. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 04:28:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 736EA16A4CE for ; Thu, 10 Mar 2005 04:28:40 +0000 (GMT) Received: from web52701.mail.yahoo.com (web52701.mail.yahoo.com [206.190.39.152]) by mx1.FreeBSD.org (Postfix) with SMTP id D450E43D2F for ; Thu, 10 Mar 2005 04:28:39 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 76570 invoked by uid 60001); 10 Mar 2005 04:28:39 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Js6MjTZmuDxs+5qJW6RUHTEiYq8+imeIDOGL+olJfdlNwZynxMP9H2pqZ3x6wxl6NNM3Z7SrdCVucpcrOG4Wg3BUmo7jX0BzAUaKEDdnP6qU3F8SudMWxcVaA8G8Lqt1JWS/klKVfuNRd0SMazSYWlGtWGQFF6hIRBzKI6dFkCc= ; Message-ID: <20050310042839.76567.qmail@web52701.mail.yahoo.com> Received: from [202.91.78.244] by web52701.mail.yahoo.com via HTTP; Wed, 09 Mar 2005 20:28:38 PST Date: Wed, 9 Mar 2005 20:28:38 -0800 (PST) From: "Kamal R. Prasad" To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1698605415-1110428918=:76477" Subject: paper on program recovery using checkpointing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 04:28:40 -0000 --0-1698605415-1110428918=:76477 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Hello, I have written a paper (submitted to USENIX) which is attached herewith. I have implemented the concepts outlined in the paper -in dragonflybsd. But it is not part of the dragonflybsd distribution. If anyone wants to review the src code, pl. let me know. Imp. thing to note is that for program recovery to work without fail -recovery mechanisms have to be implemented ***OUTSIDE*** process context aka within the kernel. thanks -kamal ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ --0-1698605415-1110428918=:76477 Content-Type: application/pdf; name="paper_1.pdf" Content-Transfer-Encoding: base64 Content-Description: paper_1.pdf Content-Disposition: attachment; filename="paper_1.pdf" JVBERi0xLjQNCiXk9tzfDQoxIDAgb2JqDQo8PCAvTGVuZ3RoIDIgMCBSDQog ICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJzVXV2r5DgO fR/o/3CfF7Y3tvMJw0LVrar3gYH9A/sB+7Cw87J/f51ULCk+J7q+dWcYhoaG TqcS25KPpCNZ6d7+9+2H/751b3/uvoe3McT897Ssf//yj7e//entP8//Xf/8 8q9vP1x//vZDSOH79DZ1S/7757+//eUR3kJ4+/mfbz924a9vP//72w/T9yHf n//vxy4+r6T8wP1K6vrntSCXhueFUW8an1eW73O5MpV7Urkyd8v+oOF7Xy7u z+71tgv8MHbXbpFRTPoOGWwsV97LhOTHvbxVBnsrb5j0pn1KodOlkDktOpB7 /awJluIBV5b6faGDeyaZXydjD7t4BjOCesYhZvH2YSiTSt33UW4OYzXcMJUB Z8WZYcQRZCA/nGHNltDXQg8DzHQpA5Z79l/JJGXoIRE1lHn25eGLI/8Qi/zl dftU5N/XsOvIPW+Nn3C3xGHOKzguo+yVuO2VcOuGbuyGsKtAMsKTcYjW3cMj a8v7qlgh7SoeVOuH2PmDmFatG+eYZ1YPI6/ELoywmD1SDyEG0WkjNBH1WOnY 6WrktRjnPPLjMLrLuhrPn8ZeVyIvj4xukvnGWPRQZTd0D31AGcxj3edFH06G tGzA14dTLCuviAkmm0Cv1/floRQ9dd+ZcWtH0KhvzWIWhIyDmV/ZuyL0MW/y jIFlc8Wk23pfsqg3L91VNqpcfAe8wx/eynsH+JVI6V6uLfqkB1yBxcq/W2Sz Tjr6d8UL+fFEXiFDE4Ta95LIp4NFS/BkMp0G2XXrzqhk1+dRjjIdgaxQXjHr QKeCLGbL4UBQPndYQ/zVpUzSSmPVll22QUQZUgaWXvRCR2KnEjsFv9encsd1 78ayf/K7RfhoAPu8IW5F2DHqwg4fy2lYQi2lm+pS6HV/XVZrXBQvzGSTyIBk k4z643XJVnXe744yyBHmk1CVy0IkRdYkOyMo3kywio8uFYA0gqV79AJa8ZJ+ hb7cNev7jM6l8znhqEbjPygIFQ/HaNmlQdbTen8lbaOdjkQvRx8ij+Ahi68S KaBuFT3IqtY+lQxdIMfsr2BU0C7sitPZqSo+gRnitdPN0qKbCuC6Z6dPiRme lJ29/LQk5qZ2wfTWD7yAp7jGESH0kiFmNCqtqlNeYrB8Xy3xGgb9DzV2yRFD KLd11iefQfnw1VH3sDxOLJ4DemLFBxiWY9ZaxHyBe3B3j5VmIpwIztolkZeJ 3RiLNMwipQaRD6uPchQ5sdE4OeZg7O4PGCmyEikIOk2wyqpiGcUm1Btc/F5u C+AKKtrlOErdgRrHMMQ8GPAom90sy7tGkIqxZShmZj3oT6rkfmtxiYc+IJxm bzz/SdYiJ2L39UVjll2v0JmM0XwP7xJLu+u9vVQMswHpC8wUVWci78gx4juo /qiLqeK6qubMqowPEU6q1Mld0LiU8Eu1H1F2LiAhL0wEbIQDMG6FmCLB8Gu2 f6k8LyP2ueEIs3ARDDNrNsLsw6lSrsU4LrMn1CRKriqRNeVmHM9JpSiGx7rW M0iR7aapQTY5qG1AJgD0PIm5mv8UCIi0RFGAW8rXmJgvvfZwgPpAyK6sBEkQ NViVzGFCFs4kgknwFMfs3GAaYPQyWHZlJYPxY/sms9Kttr9GKt0ONRVooo27 kpGqbGKkR5gBmmSZwV28CTP+172JCrMDLmI2wgJYvY7ewCLqg9JfCJSw17P5 ykOb5N5R1y2pW3l8t3ju5+8GbzvW2tAi9H6JgKZ5UIWeQ19X8GmFuqxvsxiw ZHCqjXrIwFooKMdr6UEOkfgxlw7jZxYi5lHL5jfhKXqdk0Kwu4DTatPQvqvz kV1qdG/UcWXhEEDYw7Cx7vbfxaQkXx7JbAgC1Q22ZWuVkgjCj5b6J9u2MbE7 maY6PAad2LVhPccJUehICtQE75mDljf2KNvLzvLEMYR5jbjAxFG8lruMO3kH d+fxsZTVxh5C47St7ZSRXRzwtHg+QYYu4zyE09UpVmfwqAWRoyu0YfgODNEq NBvnGg9cpolm9IusXb8ufn7t/rzozAzDysWou+MKUbYFbRuaGsA2GwFKVEjY QcJYobfSgvZ9RLAiLDd6OURkSEyhV3tfkQB3IIsmGrkTQklcYXE4buX4Z/Xj NdqdVFj4DJT76lSj95xVbtrwTiYVLUnGLGGDoFJXkjsqqFGjqKUSulL1MkIN qkmU49AcLB2BPjLqtOjhIxucYlvU5Sdjf+9E+TXaV+hEjkFTqNWsJZ15Lr2S 2rOpZMhErToCjkD2cDYZ39RZs74OgZEG+WbfAwCT0qUV2RTElTeuMDoviW2w y3M7GkVFdFQlbcpH9F1EdUMubncNxBRgokxkshwQA1XY2fUN4VqTbDpMKMYQ Esrm3l3XxYwx29IQU+yjYPdo3PmmoBHHnpeCOKrv3S3roqx7jiYMwMV6lXxX xODlRnGIfGSLDi0Z2DR3UMMS+4AeT5l2Gdw1yPNtlUGfl7SLJv2berWY+T9b MlZpGMDSReGrLAhsXHmBK72MmolxSJ0n7cvzDVQF44GqB7E6kkWDY1SLlwwt tni+UO36Igrd0I04xyrXp2Lh6Dlzfr6Ad0J3w3PiCCbmjpQcSR4CgdagJH3C WKMl+CW54aKUH+1phGVkB8kPCYGKSvHYeMqyjQebJL7t6C/50AOFDJ7XrpqT TehI9BFMPcXmTomKmyKwuSXXmFIAM0jefdenWVaIpORWR1WGiXbLKdBYKhFj 7De9mPpdmZJ3WTm1xttmX/Is5mKVxdPpPh0lElW7WJm5Usj2BaKCF7dBS9ot wNquIRvKF/mNWV1SIM6/jmkjo5wvJMdxN5HifLC/227IOLc6BHnXNZTApG5E T5/WAayO9fr04rvZsgHj1NlNiPM2YgUzZsk0oaVc5kdTTy57NWpWJSgqlY0+ 1/I+lb8izZH4U1SLHYRG3uLHpUc3/GXNLyZg9vgUzFyeFjp4FMTmQBxKepJ9 LUZWSOBieBfqzHbLUG4rPEulQefmkAhKnQ/CLfU5R3BX3nPAWkEB4v2JPfFO DBzMJm09Ve+2FYzoDrxY5DKD31nbKlZJJb/CrJuplNnv0gIudb9MGQhxvzZz Rcy++BllMT9jgxvo9jguCJcNO5awVRdDE3k0cBg3LNf6WWPZO1EGwyVh4otZ G6CNyYZ5bK7PEkvkrC+Jc7lZwT5ABojMmtS+NSC40ZRFlqXSQiiY0LerXsYl EBe4wU7GATbu3bpWMVjtj4oZttZhFXkqEzZxlzWsNhGHBW0TKJrjbZhY7GKq Ig132LbfSSi3ZQXuhgeYCP+iVQmI40GqYOo8uSuFvkcA7U35q63DA/D8bD21 cHeCJ4ZxJ6lcDDkvccqYrxyD45Q2uTLPpIbI0SnKfrF2QFlXuz8eW+XAbAra DbRMKzfZILoUsVBwy9eh3i8k1KmZZtncXnUK6F1P/E9Mi5Bito2nIdWeJFKt raNhKXtPQLQgDaUmBz1Ydv7g82rUBzlbMy9DoSIuBGe5m2AzdpXMlSEwfgjs pTARsobFQrQyWCNUGX934A+08GWtvghXQfHo0aakFDpgLFx7R7iWmDuzBUGq D2DHjduP2Nrksp1WkVp6QQvsGgTcTVhf2FgMYcOIfWkx0+OUz0qN2YEU/8gt oCMhOTyTxe491gsLgYjmHMpIl4NEXSdQngDiggG35NRQDRqSgWEZELlRh9H6 XStRLKQ4kZLWbvm7qX9N5tyUibwZ3fIQt8vUGK/lQzPK2Im2ddgBTpZ9JgHk WurVr+o3uyrTSzPZCMhBCSrEBrHOEYolabogUHQiqTOYWkuOjBwpCpjqwIWs +fasDcwLXEOn6jhCshvteVxDPCqsqjH8KymtvRqmyqvcjKnFvc3veB1MyekX Uy7gABgU8rHqVIa+83YC+65bOH3xBOK+o4vdIdG7YaFbi6jIqQHUpgOV5Ypo mFnB4qg1qJGUyDnI1AR1KxocbEgKx6iyjUhAI1dZFSxVJgh2yCec0zu1I0QL i9YwUhKOBpZDaMn8hn7Aem8vkAKfzByYh+S1X6Ooy9qSeWtVV1JzhCQoLrVh oBxde9kTRbfhVhRXAx92TJfQq0jK4AQfTxXYl2L0LXvLpk0k0erlsax6ruSJ FifMJOh2k2W/9SEguIPhR2vO7qTkA37cVC/5qxSI542JeLtkIBTjZqindQ2V jTicpC0XZ0vASm2KkRdLrLRAUYdJTLfmy4ndkS5Dfue2lZrOBdOj6TLRQgad 6uW8nh5Bd8gmSO1ROxhpNF4ShiaGaMo3FsSwR4TYKamr1UxPCMuI27yhvHTd HuW13uNnkq374GfrlNnPmt0XW5SHxQGfMhuFaD+/Y9E9YUdFaGhxmd3QuPLR FTU8t/JZXiaMzAguxslar5nsrQUIJmj6QzsO45993I7DEc1pGj4ZGyqr3RDT HKpntbtDbTDVS3Nc6YdRr3Q+hrilHsWI2tXGMr3PV+fvMom1k/aVesbGUzus MtRxHybPyWAxKlqzidQYi4I5KfnX6jMNgviLvzX6qZY/yvIT0yT/fopAHJ/z KcRrWOJV9M07nwq2CXkEUiNiDmgaSszUyzgsmEmandOhmi+vjaa7uMMip6u1 9HRsKT3Ncan2axLVvuM5B/UUHWZ6CIvp66R16cUujIrSH5Wv7hMbR3BngjVa FhYI3yxdnMJAjJSqnDmEjc7OC3YJnLyW9CgrVyHnoQ1VaAMvwxJ/NftGTAwG UGtVnX+QbRfh0JNShVpSxJhgYpMQoE3mAcMXUgRSQzfxZVgCuiHx5hqFQ8OI cjlSik2ufblumkW/EROu2QWyhyZfTmDXjIGvL30EP5Um60jCo3jy9BiGrpJJ oZpEOkqy9hsn092u90ypjT409QcaTurKGruGbOdwhPL1kw4ofQmXZAqnMbEH WKREzcZnNvPcIve4YE3FHwIn1PIY3aGZoqx4ZX008o4XdnK4FDuNaqZYsRPx x1oolpv2ClUoo4fm3pWdOEstlz3hi3fruNiwrZk4yalL8svfrcp0Br15GD/B S+62nHqP0UCCdMlq8bmHjhwhn0iayT8veQ77zEVa+/OUxImHS0F7kCVPhghN v0pfRsMvReQTFbqkYhGKUirtP1Q+YIvaq2kUaGonHyZho6u1KdxNNEi6pt5C iwXt5w4S5fFuJmwCmmepPmHaGLLcTAG7Ql18uNxQEUEBNC1b8fAMD1KgBVC/ 7Amh+zK6FGR9BNP1afyjO/tij0C3TqXbq3HvUlcsRJlrCknLsWQjXuIlxpRS n/8MqRgks4otWLv2Iajzt7+GAgRWGkZ4zGt8gO1D+0s0pCSCFpjvoeBLOHTU ifO2A6uOgFga7EGvvYRtqSM2uPl8o8ldWj12f/2qDgmyCaIIIs2nT4tDuSIe B2YONM1oTovf2tQykJaaF5IRqRkgIFOKftnj9qhfUdyGGbTJsUvGtXCyrU5Z nrMzGlo/tfX3qJhk+TEW3bczyVvDrj2hk39m0o2+WLsRU2OnRemkfdeBu3DO 4jvVoKZxwgLCw2b/74dzG0qaEzKkLsLC9pV9mGhnIVCQFo46LdjU8gm8GmOL CD+wvLJbxPLiPjiPJKiLfdFC03MhnDTti0uHFAMr7FCEN2mdUDNhvXFZsUcG 1vs47LtWXhlXECliXKJ7PfUknZYWnGIFC74ezAFyiCGSWAzOZlX6eF5r0lQF RI7Hgf+NlLiUMx6aOh9OS9nYgAR4LZ6gbVLplJ8pN9V7cUbCtImPJp/b1yO2 6/x99rWtN5BVwgQkqssf1Hb13vkEJax86Q2YhqC9fK4sF0QajdC+NDCnln4+ 4rPZLUuyFHlhdHDmmy2fHZyDHk25BWoFCPeKp2Echt4hSrfSqZW5FSVyPIzP nqbdtaMnHUNbGzFiluHVsrrfpAkRzIHUVxlmw4iUVHkeahKQ8DOmghJ+wr3X Da986STMJ3zlwygfYxAsLXGRNpBCcZGoorudy0BhjPY/Rhv3LFkrG4Ggve2Y 1GEYqULw1zxgN1AEAxIxvXQst83pkoa6thmb9m396HsXvMaGEH2YXbbtbs7J 4IPRh75njtFPYzH7HhfeBrFl9F4c1lQ6ewvKFA3nS9PCj6QOMwe+p2qgqbHc OWqi023i0mIGMYsUayHWyZ590YPjNn1cNd9UYugchfmcfMkBVgZeQKUgXd6E 4nGOkB08LQTRL2mp195apIMdCpq6f9Q2zGT6ZOdeKnkRRSEHvMltxEjBGCcS gpGKU/Anpyi5TAcPt25X5qOHZ7GhabR/KHWQ47JfrxeIE/YIbbI1WTnjaJJV nymNg4+fsEyYbWqOfTKdrb6ikdIbvS0PaEjGklodwf46fWiWg3QNODRmN4bj xZNaJI/qS3bAJr3MRt7N54zcT23xxtK81WkpY/vglHVDd+PG7g4EjYjdQCza Og9JmW3qPMVCPxSPbLL+bmxOTSJvC69jT75dyAIoOBGL5tgriA0dkfqpx/iy INn3hfpnT8K193JR4d641dhm77QQ1GAaO/hA/BH1bM6+B0G/b3F6xOdYstZU /RsT+cIhIaJWlsJ4bIA4XkL/HDVRQsSfeU/+GfR9IpGcoXiIViQQqAQpUz2K NEteUVtWeTGRHkRh3xGCKSGzww6+0wr9JJ6C+DOgj2mu78n+LPgcSA6nRYte hvNnfXxWwryWffYPzFlbPj9rESQpIbDvQVrafuAQ2Ds4m8oiB4VsXWVjn8we i7YhfwEj2w0Aa8xZl8nKY2CtD+4kZmX9k/hnN1ta2VDIIch5245opUbmISzk O4D0EMqjm+BikOPxbp0gafAPlnpcd4Ph9p027k34BFrfVlDVVNdM7TZzXo1N RpfkkF0dzbefJlsqcEBpX5Qz+b7fb7ITWym2cpfbt+x2OFBo0kv6LQa/Rc4X eIyt2ULBeNNsoe6AgnRfi7uxq70JBOrYg35/zphkM/GW0C5M5KOBi/HnbL1l 0GjUieQwmJ48uSr0tSV2Rv0OvJOTQCouPRVH1EbitM70z3I68pH6bZZrwPaF 28mR8gK7S/x+VuDn6Gtb2JwwkI8XRv1gxmyZMpwHpuYh91e2dH/8EjgrrkdA YE1L32GF2UZtqCDfqiiJSNu+Lcy+RnIx5w2MLbvqhyntmaDTlvW+xHr8pGEF 871X5OMeHDwe/UaKg1R1rESC7HcDf3fbhsTkaoL5dp5Qkb2RBGndZUVGivlB 1Kxjr5YcYoMqPY+cB672wevktDZhbZFWej0jSU/ncr56OtAoB8s8EstsDoS0 WubyU+z29zkGDI7yNNSMZ2ewNwGTXEZm96QDQZOTE8mHB9kXjkj5E/2O/WuZ nyby6RN7GA8yQqHtqlG4g18msttaEsLaPBHjHgiIEb6FNOf5wqETXzE68kFF qhhKB1jGxOEDzKYlnyxPW8lEgcUF5wXb1SNaSM11fK81i3QRlHTcuc961iUW W6Y1hsX4ETqPQj3t138jndEDizp6gN4WxVjIhyET+R5cvMHY7zD2NvJy9VjW gyrbB1x37LdBs3cWywmR+RdBwmzqSQ58AYuLfo8jKXfyTTD2KZwWac7ki5Gt pUNtedpp+9qfhNzJbczp9MuzJwK7PkoyRJkNZH1Y0Y6jGqfwzr54wnJ8nVcF 42QzSEfftccdVUOmxgdB//T2f8l5azBlbmRzdHJlYW0NCmVuZG9iag0KDQoy IDAgb2JqDQogIDU3MDINCmVuZG9iag0KDQozIDAgb2JqDQo8PCAvTGVuZ3Ro IDQgMCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0K eJzNXcmqJEty3T94/3DXApV8iBGahhz3DQX6AUkNWgjUG/1+u0eGm53wY+Hp eV89EAUFFRWDu812zMzTff3f77/975f7+lf3w39NPqS/5zX//Y///Pr3f/n6 n9f/5j//+Pvvv11//v7but25+B/h6+d/fP3bM3x5//Xzv77+4i4u/PXr53+n W37E9ED637+4+LoylX+v+7/T0/uVm1/c7G6v6375MZT/ePCt7lKu+f2aH15X wo+x3DWXj6TdyKPX+mXh6Z77bf7HXG6b6veH+XUl/ljKlcWP5a5VVlbuKs+5 pax1/DHpVq9u2T8aZaO6Bb4STz/gY7ky17TWRdz97IeyED8DJY317lRblJJy lzy3v0qWFYhH+yIeSVL+diY805IoVwnPVDa0KlVndy1X/aiXWTCeJHc3t6bH LyxVtCcffJIYV0ju9DsXlyVzzaQp8hMDcJNoOLhZRGo65ZOPTrYqvBuKsMiV i5drIhfeC5NmFaqkd2mN9w7Cj1NibkX4pZY+dy9bW3QXU1mzB6GUBYrEPBIt 7+XWEEFBsnVw0c26+zjomzKph/T0IKIfVNK9H8U+KGFfLxTpUAYnqfeFGn7V tV2U7LESnCbRhoFNXVprEoqdGUG+PVfW7kIiwkLD0nwnsiY9dk8hq7I+reLG bEmSs8nttVreickrJm4FE1fLbLwUKalX2SRd9OmdFenmRLzBzyIiItyiKOOX KkrWTN04SD3T0a2+GFfUdxe9kzc4fcNa3gHiQLrgA5lA09SrxoiWL5UsLF4c B5KfX8c2tRIrw2EsaKSaLNk04siSpNyPROWRWGIsDny8XBO/o9ZXtTwJ5vp1 KtizzwYBOczmVQz1vr1Z5DQ/Tq7epI6wWu6aNul6kLUpZABLfNNdo5r1eDo3 p78ragc/k+BlKS/uJlnBLFLJiO2rHlUQvFB/ONA6PZI2UwgcVaBVKvygdPuW Y2ciclTFxE9rnph2YvTqOK5FzXEdyJygM2U5G74jZ7I4YQ7tconCQpGbme4S g8Z0l6c2McwGKjHqguwavRGH6ccKw9aW3Yi+Q0bHJTOrJxqryJJF7l5onTSo FYcaoTAt14hoZ3FYY4saVzeziHFco6oQmvFgpQrC2CgLLabIA5PIj6fbFq+p yHmu4NG8LBUVm6ybHZkXw8gKJeTKtWLlWlYPBEwm5UZse6qRSb5U1mrYTNpk cGT2ujTkLMxjVWIG6Cc50JY9RQkWIbg0JLbQEeMyjpQt01betlQi1eTtmKOd mrfJObh9sTM4YAl8AibLW0RUVhgGSEk2zb28gvHy7OA08FrP4tbmipPbOa43 XmvqaDyl/KUrERJ48eHj2ZIMw90Kt8GyzRU7IIBJeaeoBGSenGc+QTZZrFXn U+b/YMYVz3JOC0sOL5a5MwCCRMhLEgLJ7JvM8yuH6ndnpx28yrLypWEPzQTM iKbZbpNigy1peNsnsDBWJD6hhV/m9N0jMcKeJwOwhBImH3EABBSurcqMWW5T IyOWJxgvbLLLTeC09xXWeR+gWJr5AYAhmZ/XtKikfqJ3KU0KYbMUxZAshu5q 3JiRCMlzDjCFOF/V85s4vknvFMERo+F6nOGwBkCVQhXHePBWou5i71ylhylX U8MYguGeOJKFdOFOjs5XH8jWNxaehIM4HWEQb3g8uTLVlNKID/d7Lzq1oOeS ALJcU6hzrYShSfYZE8oX2ZOxK3wdjYAMIsiwmbMH02GE/LF2yu+07+ZnvngH 2gDBHl4BWRGHZfeQJdLBbCt7VXnNIk8YUiBYtTAiML86CDxNtVQnhgYB5JKI AOopGSLsJ18mgqgnHt7RjRhRCDkYjlbe9swCXj4cGedRUFMTS3nYMCxE4YfA u8h7MXTAz1nFvUnpMW+xtiBZblSFUEazEmd5GLJ1V3EZlrZ0smBo1iyCMdN2 k11XMx7UiNc3hrmo7azuZzWYfduW3wUcD3GFRGNX8kUkIxp4mXxIwg9gb6wX rQrEppYLQmoQwt13eMshjBBLiz9fRYCaFl4kQKUoqlkL82axi3gAKZIVCZfy BGZLt81PD8VLIvjEm2aruZJoZD6KhILJDZOhvOzhOwi4JRZHAsbrAZtdYH+Y s4WjYUY7HD7jNhvZTGJ2d5tMZ0OgbInLR3l1XBeO/9qGoA5HWcSzuElgdDDO 4O/NDFeuDIATcL6JloIUU9fT9KaaWhxWCPxs0m3JsleZiZ3lZZ0RXJDJ0Ibn FW6D44kZADUuk/SEQuMJH9bqKF42ggI2DJ7Cr+zKcjWb40aGYESL5Z4rMbIr FYiz57g3G5gpLScZOfUHAxYvBZV1uO8iX078kKVhkdbOVnMm4riuSCLZxket TK+NuKukIONnkULXepMSdoS7cVw48erLMirA1ILjwWka+Rpr+tVwwZ+EqGZ4 olVsUAlL1mcvMHQA/zLXLA0LfAo4HXIS1ANRx4EyDJPkDS1TkpEdlKdmempS Qt80kPFry0gjXtmUuNWKnwgxSx+eFD0IDrMn1SdZOkIKXLLkXEweLPImmv9Q 6QrlYk+sEKOnhDAMZVtarQBPIxZ1LjZ6hTCqV243Mgn4MQMcl/byFPpBnKAZ oSYnL6hji+lmiejBDfSIq18oWs5a5TXyUcAlfWUCHzQTh7RWSlaMfQiLoyaE riUQhyC3bHKAyHTtzbYU18DtoB9RE5IbO7S4Gj6rfiTnzenaHXjNr5uMAgVE Vwqrkn+Sf7/45cTLQzxj8QMqRQIGL9rZo3VTCGPcLwpjLD05Gl0/H+LQ9zQP q6dE4E/BHSsv9lGeOEA1S+gGfUnYFFTnKlA+2URJmpWsAp62AljSzSAJx0Qd Yh7mmZPXCyA6rNXaL/DqtUlS22G4w+go6/H6oQFpI/C7IAxuMyCDlmyjle83 uHaCJe9fPzR4bZY+hQBDUcHz7zxpoVJI4g4A8RhX7Xbw4IpDLr/1mKYQZ4oS /z/gJRwOzZZZD2cW4hTYhhpZDW2D1OzQdh9oE7b2wUru35Qh8+bN587AHrAV B1Q6FhMVmkETB4oXlq7cnJU0cNwJsChqMSqzwqXrVcX2n1oUhZUOqXPdjGZg SB0c8Y4iu1MsWnsIC7VjRw3ZL5F8+ot+oo8g8mjoG4k1aQZn7j0WypOdiKWu b4QVjUS4Az0vlXPQtGf9Lb+zDCJdgXkbqIU8JeLxUcJMva6HhlwjggHXaBVH ZDfXnq4If+h4EWTuofhSALI+IRGrBR2hMcN727Umyhe6KHU34hHNt4xgDwsI 4gGtrgbonw5qyPR53iv0XUEXZYdL8+PEYchnmKhZhXi6det3lIJfbCbNk+VE JXEpRnZXMI/YS4DwT4ZA5p4Spx8iB70bwiYbDxiMawYOAi/NQ+IoLRzfiuoy aXzuD4wS8FiyUBfeksuRytoANDWiAhPuRHinSZ3AzRIpS4nFzMBcjpEX3qDS Cy1T2gIEKhkZHTDLrLMWGsonh5P8lHXgkJ+iApplGm0DUCo2ieUnRsjNarlS wOrHPii+hTZZoZoKpj4dARk5NiEwU6hKqVdQ0LfiSySieWllauDIQ5Y5eBgK Ax0ZjHfcAgLNlVZ54NzUVLWqWCUg/E52iIQ1QleZoxxFobfba75EqABsnRyC SALuchphhB3yIUzlNnRsVayvRd9lZex7M6x5eqBYuAgkwUoUNCl8O7O3bFdW UsWhp7MsBi3G3v5YFPtYumRz8p4wM+FQ2V7fZcrlYNna8dACyzcMQAPlpKjy YRpcIzx5zX8o0gGG4KXNd2VZHEh/TygTXd72tDhOhU0vbsiwFTv2RFwWArRJ qtbIja7wtqGlj9gMStmKFYil2FHt+WfR+RkKAlgLin2j0MtIUUOz2q5/Z+40 ca79OGeQTg5uDTOXXIbcrMf+DAw9KPrurdGCRpoW6GvUTGOlYKqX5SYsWNKT 4lXJq+XgYyIRMOoYD3V13polBidvNGZ1IWj0zS6VHSO39J17w1c3y7ab4gKg a3GGOEakXDC4Hhy2s67DlawWjC4C0KiJBMi+1obSKn/aZB1crSpPy1aMhth1 5d9YUGyDdpqdHUNOIzAW1K7Yr5Rg66pCLmuVPiacWHoNRe7u4yFiAS2WTjap ldhNxtph9E7LMHHtpxMUzzMs2nrVKhGVNUK/+sNyScnkKxqNgPH3bLGFhD+g wFOHg8XiBZBmK58BzThOifQQ3EcGXpZDLcnKMWH4eoHyGgOouCdDf02ERtua ofx9IZaZmZTQeDxQAvr4WN81vNhXXRmTiCcXaCEe0UENlztoPq4rQy7kXXNF j828jbpZdXPynwPYbIAroPsUrSEW86STvBTzPmtslGmqdiOwaeUokHJWEZDy Vc9WFPGbj9oTMbJvhD4QS2MjybsS3S4Sy8RQVBtXT+KfR1qMB/0NUJYDzFnC ZAxfNm3nHtMsLNLWOB0mnvaLUPneJj6wiHZAsqBCBqGaBO1wK0NnjQoZnEGR M10+eQCBa1KgNjvmwI2ixcTb3hamX1reVlzqIeAPKTiQbhFI1MIFvjFhBnjx M5HU3TPuqRwKoOUcMZpjGx0aUkfK2F1oYEp1g82hzHN506S+c2NcCVxrAGTb cNxF84xozRh/2kfTmyYiII1RyLBxeBaqc6+PosVxm9+Uk2vAHM6Qu+CIXMlW 2mQcRiOpex1QQCFO+pCcdASajkMdrfppFfcfNcFzHyK7WtvsQrcSBBZbIrF3 YfaZW09w4g3efYgeRDuDSOsAoTILxrlyslE+1q+bdTTvJr6RAtHwDlDdCeBG TgUv+o3QSrLcLer5NDDVv00dx5Kmt8CPQNuLsY754pBeyK1H8RlLQD7Js3pJ G488BZF4egmEMBSKbGdKFA8KiE2KY+LUQdxhO2itjqn5YASz3HB76T4MWEHo Y4260Qzi7VAzVPkjb3sDvA5drrMQLRy7QH1mB90jf8O8cD/AH5c/kT5IZi3p C1w6UAEse9ZafbkySN646qsGeVXji2N5uRi8S9TREO5Y4sOT1lOCZ3PDBWz2 Kz2udphGow/wjasVM2+BKefw3WF2mosmrVSGu6l5BHOBeMaavmlN+qKhUA8+ owaGZrPUzWqZMObcelgyesoWN3RVQbVWoypRHebdD1rmNWc4N1DcK2P2Ihjk o9sqKxsrmqCdElXxsJB4j1ziDOPgRR9xckwPWAKTtnbhe0NcuLZrRifYaawz 6K3xmKYEHWrUAENPljbaVpu4ZajXQ/Oz3oGAnTBhoCzprREX6/rI9lpCXPH6 gS1lsabSgsaDtpdirDECoCCDxxUapvr0jihv4dMuzpOkl5XO1UNx7K1hE2Lc 9yD/wXsu7e5meyfYaqRo5qEkKFcWCBDQ5AZEIg2TbvSRQNSDyc139QdOZlkO WNTBAjabcY22Oy+NVk26x3XmXGu1SbnHewCe8Okn39yo6IQ2M2g1QZXdKtts OP/rrJmj4I7oH+JQPILXc4i4fTJKk6Ma6sL/epa9Tddl+DPylu640Qj2bgOj Jv4yFKHV0ENMG9mRRqRj2hEydXTbajarsZnpnGkzGoKMYKartBxnSo1yk99V yAVzdA9fp3onexBrdpxKP1OMXI7SxDseDtcy287OwYzPsYc4zpT6DA5mMxci 6Ip9PYNRHrFOVfHD4YBdPCrp0HvQPsvnbKZpAhyq2bR3ejbKn9ZaqycmgHO6 6ll4gWHKNsOGgdP5d4250BU1HE9PBjjS6o1q1nIgdQJvGTowAobtZJ6XFgNI wETOgnMM40GYddGj187ZjjWHHoZEx/WzfJbVVSUQm79EBBtYtCGC+z2yp2IC x4NMwcHWwEQTgcF+3KGSQMT0zBofq+ajK32M2/HwP+sC79NNxpHchs9sKR0e gWH4ERWMD9HJJN2fJxa/zstHbcvSKY2C/aArIYgxOrri6zinleHIGiQ0wIbO +i5j7wcoyMAFPkIewuo+qLusFujN0uPpYKNvdvFw85cgTBV6/wfLMdpoo+8N uZ0ZD8RX5wrldIB6+8rpb6YWdrbMRnPeB/7oUKg9nMRygJXAFApRAJ3IIZSm kPiOkqP4QxZpHxyEHdfqBAYruOiNr8LoKuKEorq+hReyT9i/9mGfhXGkRsRf vMBz3Rh6tODPV8IuFNFj9Mun4Zct7tuojNbzGnWqzvbarrm7LjAixImSt+zF Xj+DINHRZ9OxJ3MiE8gxZrUlmOVpnWY0yt1HD9PlJcuwdjUEc0XA7D+8wzfO C1bZ5Eh10IjwPrQvgVvCbLxTFiKpwXnlrEqhDtPDh9apCMXVCRATbjDC8MNQ mwxrpi/nU/wWES4dOGNDT+7D7FNvVCPkQZ7F4+hRoLI2M9zKhTI9HmisEg0Y LjlWM6TLAQG3NyOcfORRYxz2YY/H/aqEcIEmojezdtRWZA3jkwx9Kwh5M9vQ tFLqr/nnGpoi4VejV+w9psuHgJ8X67D916OJsjxgnSh9MMz2+dE+Y45QJA9Y KV1rU24JlDiGpzqfQ/9jTbe+86R6nCU9xWGAWEPfPESy4yQIy2e2ZoWxE9do erIcsAlrk6qYjZs1brls06ldvJyMpjAdWtuJHEF4JdrH32c59wLQ32aO0Urx 2+wz8w9J2Btd478wBMvdvYUPYCDlJ+1Qh+1Gp6XP+owjt0Y+mr212N1S9wzE Vsc8AwiGErIOGOOZdSB0mKFrntdHQFYS5BmO9dQ6FYWWTRSsgcrT3Oix7Q8H wmUPHAu1uTjgj8NoL6DV9M8HHp6cb/86LcqY2Ix+G8uUSZNWO4YH69QcnfpV LgUdAIZNHCB2maWw8Kiy3SzgjWYBOHQBzWRGdYeSVwf/2ZCJEb2dDmXR6/4Y EN/fHnTeHPP2VHiSoO2oWfyFzDbHPLdC8pl81rHq56jGHbAYufy0BRarX0vD kSvU3D6mksiBjaPsi2Dma980wJCbaki0deBE2I8UnA/pVQOa7NIeZ5zHgWMV 4GDN3sVXEqRdCHg+dIr+imrh2Hg5s2ruMy77ZR7X05NI4TQAeKmhNE9z6P+Y yTXptXAX5SFTwtEK6OcGyxKKVVlrwZZqGUlWI9I/yQLNDhCMWODrYner4Qk9 fRmmwjQ2O8pG5UG3wwTeH3b9Iuo8crnvDxw/acKBOlZ4qGXYoyPdx/729Bya 088nH9lmhob8M2yg5KGZH9g7qH+q6G9f/wT9dTTeZW5kc3RyZWFtDQplbmRv YmoNCg0KNCAwIG9iag0KICA1MzQwDQplbmRvYmoNCg0KNSAwIG9iag0KPDwg L0xlbmd0aCA2IDAgUg0KICAgL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpz dHJlYW0NCnic7V3JzuS2Eb4PMO/QZwP5w00bYATo9W5ggLxA7AA5BIgvef2Q atUifiU2ezxj5DAw/MNWSxRZe31VpNzpv58//efkTn9xH/40+pD/Tkv5+/uv p7//dPr389fyz+///Pzp8uXzJx/9x3Sa3JL/fvnH6a8Pf/L+9OW308/O/+30 5V+fP00fQ74///azC88rMQ+4XYkuPa95vjQ8L4xy0/i8snzMdGWieyJdmd2y DTR8JLq4jZ3ktjM8GNzFLTyLSd7Bkw105UoL4ocTv5Une6M3THLTtiTvhBS8 pkUmcq/HmoAUD7iy1O/zDu6ZeH2O5+439gxqBvWKfcjsTX6gRUX3MfLNfqym 6yeacBacGWYcgAf84Aw0W3yqme4HWOlCE+Z7tqd4kTx1Hw0x5HUmGnxp8N8H 4j+/blsK///FbzJyz6rxC2pLGOZMwXEZWVfCqiv+5gY3usFvIhAV83geLHV3 /8jSci2C5eMm4l6kfgiuPYmpSN04h7yyehqZEhsz/KJ0pJ5C8CzTimnM6rGS sUNqZFqMc575fhruXKjxfDQkoUQmD89u4vWGQHIovBvcQwagyTyKnpM8HExp WQ1fKoq6zinwnEaf3J30KARlwkB4r3kBE4sd8+Xqg5vzKGc0VJH4mBV0lmGm rFLb3cHJG8v4bC2Cq/Qqio5eQXQ28gWlaTXTiHBKz/IsSNe0Hl39mURD8YMm NspKzh00D1P+u6e5vzAZB7Fbk5JRXClzeyTG7FhQ3yYmloda1INqqRc2zzPI t7Kh+IYzMGFCifFjJvLsUbwM23gVZ9ekqC+SUEnxnBXjwS+ZhcHCXuVSz97T gpS0ejAHbIW0y3mwgZiPiXPPS59zFECWXEn5TAQXQ8T0aQ050fyyLtWuW63u xmwOws9IztM7mUaiO5vUdo7MqVD7nhX1jMLECsJXiiXvYOkwFVe3D7PC5B81 ndhgk4mcw5LJnMMAdpBR5IlDEb7CAsquL0/Pd1BhSAtNMNAEi5FgWi+KJfJi vnYjfVKWcWJtnw0V4hmS59RxF1kPL6aM1AmsN4oKq2A2JZ4Hy4aYB7tQQIDq L/FgXj3NY2o9eqOHZxVkqYgqwKOoBBJjCc2b/IoTeV/hV0DFy7Rk46RiSHEn LMnnveSJAVGr4qdSY+3ZJmUV9XOXXmRbtlTLiI8s7yQ5YqCzGlxB7FiBmOU+ nFl2hBsQWN9zoFpcevbfYSpmmdaf0DMpiZhLzuFJoEahwyPMHav1Thn252pT ev1cWmZlorYkDUXnuuega0e0y5Jnb448kx0elOuqiZGpdquJX8hD0gBhCksH 8SICE+uZy9siWF65gjECUSQkiuoz4em2FEKK5I7k3hTiA2Suh6lpHkCE+5mj pMt4hq6hkTuYkc9Sv9hTOnvLrEoUyfO41O8MHHlonRrhtqk25GEhAkp2Fl9I 5UrSKaow/pvKuzVyrEkg0QpbR/ZvfCW+et+6ktH/Ac1F4ThiuyuhkPmy2qyz ECiz3pABVneKPeUpTtRUjI8yEFFO5i4ZSDMEJGnoeG7NOysiPLK9zzaeZpcz lvH0hoavCer7ZjuuIvcnMd98GUZl6PcvnEFIpCKBrqhEmJQ5layrmFO6SCxP KbBkkCkl6yoYHCE3BimUgy8OveTMyl93yU+cJ5SD70Z862UQLHkDmMxu9CwZ TfAYjykVVGZYcgASajGxJNPRiG7pzZGzU1bdpUcX4pQIL/5u3u6Q1MUimBMo cX7+J2eQRMhFUCYwSWkUJJMjcckqFXENHoD+cPTCCxkTYMSdMjuGP9FgWC9j Y816H2lwSQLIYCgPAoRCWQ9TmsAEzCpNUpCNpxcg2sPJFELsmP8J9MMDcaC/ S2jPah4ST5ZEtMhVzmg2wkSsSFjmi6fUmc3FtKDnHon2qtQwucuLbN5nM7wf jiGNRyKTpMCahYTVO3CKggp1SW8clGZub72KWhuozqGAlijNHA9gUBE0zAMG Fj0wiBzgCJ6QmZUUOisWhEGyw+GQYIltcOQr8UyCreLoSDCxio86aB3iN/Vu fUmH9VxrpDaTs7OL5kKyiV/IUgxHSxkVChgqRqmyEhYuJ0OtOjLQEoEYkGrW yNX5rIhhAeq2mSsYwQnWHlQpCMxXB9Ye1ypDxfbk7p6T8aD0gPIacXGI6GS3 R7qgS6jo1KIKE8EEwqLkDtLYHclkKFRa9CDCglJCYFy2Bd6lJU6vyRmW+Q/4 21aeaY3cFGtZpM7SMUMLLcLCXVkuoiW0414ySuQEOnEpQl1F9i1FEUmpBi8i lkol6qkf9ERSxpKUhoft4t48gunoyRDDFCGCFBCaLQdfGeHKBFfkKbomZbXW cz9G+jHS/+NITf0ZPdi2UJwQVeBmMSIcrrG9WNjdtIz/M9/n8VQlPmZrcpN4 XUE5VqpCr2d7i4aUI0ExaTps370dbJ2RLznIxxFRFdO6GD63YVvLykuk0ZFT hFRDwD7I3OoCcNTdC3f2GYpxjxw5zasDvvNDyl2oomA0aDF10aIVkIm/E1DW DGjOZYJOUh3xaFYc1hF1hTiiwzBpWRLO/Hdm2aSpSsPTcbwcuIKtQGaiViNg CEX1GEGKRnFR+vGkLUWHAxZt2U9rYKMwf3s86XKtBBn6Mo3JvIGUfe0gkPhE RY09/j+UeKGK3nKY6m5coKszuGhQtpW9W7RmEarb4ppAwCjKINHUH7YL/pjW mF8YHC3WtNZQcQpceUWo5WazHMyhYYHxntjT2hU8ACR3ShGW44wE2GwZPMP7 XOuRpSaEmJQisTg3xlUNyFBVTgRUoLxfwWNsNY5Z73vE1nAkJDC8mlBTqjSx gbBLC5eyuVcPth+ST0Ml8IXVMzxJZd2ZSCyd6IO7+n58TtTqYrwYHkPbWBu0 9Gv/gtOV9l2Vyw1wW4GeqNs1teXSjoq4MGAADIeRj/TAiXNx4h/UUNg+EQ0Q xRBE7ws6In5agWrS7dVk0jyBjV+dxs1JCb9h5WfHWL/G9dERRelmaOhaWQy7 QOVqPcDTlYWsGypVE3tEemPliFeGDRlHsWFouncrdFoUCP5OfOSnhO0GhnH2 VXOb4YPRj6Exw3I91LIs1ins9TiYEiBNa6zhRIzmF7Rnd+lA9FbTV8N9GxKq 6xB+URR64irkLLRFwhizAx/xY0DDeCv1A+7M5liBnWKDp1+33FeRodZTCWN8 kMXzW5jdE6eoFnOx5HXc/YTlrRLfsRleWq4XI7ODcNGXeDvSoE2WDbqH9aj+ fBDTl4mznKp82uh5YffLstzRPmQsbzHA++wtLqqAq9rp2WEe88NaLChtkOG1 nCDWfTdqhLP0zSCY0LA72C6qwyrsOGKT31EF8nECw7v6KAPyvYvJVxG7WR9J qlNsaq3kFm49gJEPAzRd/QBcf4z0Y6Q+wNX7+F6TLjn7SeUVytCyxxOvSknq 0OxrqS2q0fFptB7Fua+1yDujuPluVXkpqzJHGo1IGyFjqxRWWsSJk1zNn2p+ C63nXWZXk7Gzk5LaMizavtNLO89oe9GSB3bsAlki4PEypw/TGrFwnKH62bCD 23CWBdy/+7n0lkvunJSvhlDAB3KUKs9oNBaqfACTnTwYp7o4mDj5OIYlncMl zC/kOroSGI0JCyYvxDjTME/eevBg4higpgvRZQQWNAJbg+tueSFo2zLDCNHI 12LaPFOE7d7ZAKR71fBtAOCyNsDI0YqcO+aoAaAJJi5wKol1s1cDe+CMhtLS 67y9UiFEg9pmn4xYvVFy4u6V3T6PNmK7CUR+FdgeI3ECqgH386LIeKv9pLLJ FHESTB4aSKQB99YtEpZEGl2kSL7JAKnNpg/e3emM1ESic6NbG7crWJu3dtAG yCLd1GXPXMB45EW3ouoEN9kr8Gd9RkBzKsM0fsiW/M3mnF/vq3QxDH4Jg3Tb xKSgcN5+pnamL8Ds9AIc26Y4IJzyxs5Kq0Rj2IvaNRsNQyB0KIaPFd9cu+1F x9Nk7LdrtOwbmwQhuDRcfx3uWB1yYorEMnch0bOCHKzsV2EEiJUmt2507uN2 cliUVPM+hOeNImLZx805u94Ja+G00OzXYfdswBf7P9cdyBamABxCvs6Sqeg1 4NkYJtpuTG+vyMaeWowLot26iQBhWOV/cxkhojfQhhjrYAiGdYlMQBSngPk0 PCiEcIpFH+t6Dbb3Y6iCrCuAvBPTtornB8jUg7t55DAUo+j8lk2DomIDu7UN htfbvyUXVLU28Wj75t82u/2A/qCAduRzVD3dqicbk73JAUTi7p3eg63hVMza ON6VepZHp2NZsVKUoPNkGhNUhkwFJDPwsy4AoyqbdavDcbpq4o0CTlleQHYr 6tRdGm3WOwPIKTVdz3J2hOX01ExMHGFrmLtp+YzaPEgUK+SzO0VK+9cmTuoU HbSiRmK2HaCTZ5JD05tYroQ4fJOCaXGIeE9rdWrTFCl7RhJ+K1qh6Uc+Gqph eM4GjazMspFO9WWkOtJZ2cZVmTfsm5S8l1ZQ9lBBLm+UGUHKDvcpNI6SsJIU yzOVWnqXzUwToliFQnyyhe5BsoSXqCaWhfsoFIqCpBRf5xugieFj3LopJDzx rO3+xRgCqoLH5FohMWaaKgCvRX9uOlTnicFbjGgJBYPtfJsl44i2LD0jKI6f BH+g1cgWBLc7diNEo2lYFS7RD1rNUTqvCkGH0qmOpnzlazwnEtMO+kJB7mn3 K6c1bdVbGSRN2pneZQuHbhDpCyLSEBHhvrhJeukCSoGVRzXyr3KGGZFdGStA SE0XYsd60AEye61hiIcpQIPBiyM7JJHZ0FCBarNnM6oqKjyrdh8OAlkNhXFi OpX0IKx02P/TZnfyaP/Wzalq5/hor7CBgc+S5GtUECCzru5l1h7VKGdstbUc ouinn44zZHOH9lWdGmZtKDi0rxg04tS0RPGqjP7VHBjN0nYlQjv7drvNxtxQ 1LCKaSDxMtws9nAOnu0ctEsJGQUGbObtxv5KB29EW42BqgGeG2UGHgkbJaEA 1WKaBeZiYq4Kc9LgsCqUgsqjNzYM71Lm9ZxHwaBiQ9nwmLPirPqQ9LSexVeJ iAIGsQVVolkRCcCaGqHZe3HrO71N+gSa48MuvhpJt3u8IBZLrTH2vTLv9W5a mlRcPXmRVvdhrzS4ZJQFvxOCoBqdVaWbAaQGDtwjCwbq6x7aL+mO4YZfauid FZ18I9C6BLHoZ43I/bXZ3Hr9SOomg9hNmYjrYd9fahAxyAGhQQX4V2DNdLQz yNy8bkQ2hm9Aqzs9e7choFr3nN100T+qysssDXnNMqoBKF0p4/GulV8US3zF Zb4+vWMj/sSHqL8oiFW+OD2xmW0+oZVizqqwq6TjomxQ0tRclOqmY9OPpW6r +fGrEkmjpxG9/jWvv5guZWnibv/62EP/EQ/D/FNy0Ua82WhIbUCQdwyVnpDZ 9krVNGGh/9a2SSs369vE1rdtoMBv+V9jU4TB/xfnim/sHCDXMcohxm6PO+Of oVW6sbCfb1Y4WCv5jpt04i7tliYMZccaDdPH+4xrU2L0dBXwmg+HFoPI2l1/ PQBRdyVF3CYu9qrNwxTQJM7WAWZ3ZcOsvdZm6wPC4m/lCLdqy2zLg1gchlUA mnTYz/3qvGJDMp8ylX9cq9g00GCVdFr2mVRoACynzcloVLStJOshx7/q85Kt EO+ssOepyd9v26PQLoFa7LAKlkZXTs1bkS6Frlsi0BveeUD7yvqnZ4jCNG6d lwT7PBBH0FCzatxp6GTHtouD8wQiNcsScfh8SLJLaYso+ZCtge5opW7+KR2l 4lj+6yylzMFDiapNc2cUarHNW04ViC1UHWGR8iGQgERG2ItdbqM1Jj1tM0aS PWlMXz73dV2SXVvbJJSRg7t22HBqWc0eVMoIrOIthJC62szCEnEb6g6+CRLU WQczGYTBIxML+kQmsIHEJJWrN45xxgeDBeklii30fu6+8yCsLfEqtJRDHl/P LZtajEnltIlmjw2GAAglVoeQm4e+qLOpdCDS3qCxycdslKWtc03ki1It8HU9 awVbYkqGsiv06Upqjq1xz9az1O4lvGoYga7uYuCbsb2tioTQ/w8SzmvF3ppo eBGNPYbgsfq0eOBj0b1yo9NaOCNZng+7Ufyw8qXHdYTooF6TrhFOSUg3b/jL dJdIOVifQmELxs0LjVMqSpwwAFF79kiwA275e9S+u4UYXUPc9dapY5t6ZhJ2 Uizt3pRPNls8/O4bc4joI3InCSuZTJV3+q6qTvD4ZYU8k7vxZYs6Vkt5wlnY EIEuP9B0OKgcrS0GjHHIsSvGTiT6ONyugs503iXWy4rTUPTjdr7bIm5PkdxT v6UAMOvfSw95c3AGFZFpRb2kEKc2dTHiyWx8yIaIQ+n2N+L17rSTR/mCRLz5 a9q0VJ1laLTXGXtgDA8l/MG99IiXN072rnYuDK6W88EN5tehzjWNWgc0qGZ5 I20z7IQRtZC1anLaL8YnG7xki0F9GTFIILkX0JefgtreNXtA0dM1AWcO7Lbz ogkNY+bBn738Gk8Ys5ZM5G1Da+eUtUGkA3tAY+8X0Ro2GYk8jirLPSGvonxk yltZdShngY5F5csOGjHNOoXvsQB+xA9EkEkhMhnbgL4r6Pv6zB3jI0ZGC+LX byTrKu5bjv153usbfcx+GBF0f9bD+ZgIfTgPfL/LyolUjtLCHfyjWN/tRsYL HjUdDfUwDl8yWp1RuaN8aVRvCrr6ax9qRSfaMz+PJMWyZboJt9+WJfwQSgw+ onxYVSlJM95uzHPKaTY2mj72FEHLElPNT+1ym8mMcrkdSaEu+Bk0P3a5HGGO 5GQVGQb4mi/5kTbb1s8y1y5ogNYH2wXxwqNRJD+mVyx9bmRglNU0qoOoLdbx SyGtiafbzmPc5CFZn9tkng1cllFWw62xZxJ5bBPP40dwDmS+f2uiCJyEN9IM g2Wc5pGlJhL0va0eahLm1BaKtkLGi25h1T3MEOJ35UU5cqsYVBivvl2szm6r IOJjo3kc1jQ3oCuLlapXRXVc2LERi7F+TMFYuzZLNpRqe29fDs4jDq/cfDFD g+uyMgt+RCddA58Y8CrOFTMQVIvcTVWWJwjydRmY1iluOPI351VvMMY3HUdB 5dnJroABhpfGOEVDJXPlg67yhWzl6I9ay4NHVhxuxsQEEL/D1WTcHKxinG72 UA1cV+pC334acWc56AQvbJGmNW2VYPeHdPP1gNHvdfOFsIY8McSQiM5paD1w kU0/cq1eG/YzV6ZLKL+40xDLJiW/ZFnI9//+6+m3n1ZunMZYBCQUrF5++OX0 P4HWnz5lbmRzdHJlYW0NCmVuZG9iag0KDQo2IDAgb2JqDQogIDU0NDMNCmVu ZG9iag0KDQo3IDAgb2JqDQo8PCAvTGVuZ3RoIDggMCBSDQogICAvRmlsdGVy IC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJydV9uKGzEMfQ/kH/xcaGr5 MrZhKWQys+8Lgf5AL9CHQvelv1/NZiQ5lmc2LIWBuLIsHR0daa35dzz8NdZ8 ticwAzj8prJ8X3+Yb5/Mn9v/Lv9efx0P4/V4KG+WGU7OXL+bL8/OAJjrT/Pk ImTIX8319/EA5RTxDho82Wyn22Gmk3T7PdDvsv5Gl+vJ5Xbi8anbibOrYyuO PV3zdDJBaJ7yALeTGUN/2cpmyKfSZBMucb1Z2H+YoBOqDyo0KJTBwBl4vgzA hzpRHyiHckoMEEGGBaKH3WBn9sdQuntoKfvIFhB1aA6gOE/hORCIVXhhbh2q ajoFUSEG1JGmjtmFMuez2Rbi1G4F44BBN3wUynDyhfIJ2wWIFBjBDyMj7ZEn Lfuq+L2qkh2UWYuXhwCR8UmbgcGZXGUFNWxHpfzYoRMneDIj5+DUxURWRWB4 phO2mjvABH4yyVUdmeIEBbFb+xCUFuGDaaGdiI8HiedsvSJaUVCeKTyBEt06 6/EbEcSEzgv6ynw3CK1GolqpqAYXMkXk/TYDFWfkRKKzj0CDWee2LVZ5SRyB iERsqyqUSTrwSV3LsJpl6XMmiCRMzqozgnAbFN8qe6N0a1pO8M52hhU4CNLN yEVyX/WbA4KFk87K42TP4DHLAdJCooeU6W0UfqAEjG4wmraM2zPZ7cZgE37V fFPe+vPN9eYbXITgUljnlD68WybImMRMBHDptM2BnrS0jYHu9BR5fL6hmWdu KF3igUD1yyqObd3F7h8VZJWkki9HitXxxcM/vl/1WIJqft2zH2eeQlln7HSn 60HTm1BqDnjxxBNybPc/tJpbNHv6o+LM1URkZ0pzselHrYKjDIBKZXRwuohg FdBacuYHCp0X+/tCIxRqVst7HBOyfRmSlKurxj83qiwq72k0upuqQc+GQS2h iaZrtTdky8NDFt/7J/dagzs42pXSENksWBSnNX3nxL9eOJiebBMpej6Z2nys 683H4YHSJauU2U82va0VVAFJQ5Vgos0x78hm72+nncSzSnz4WOI97m+vep0N TC8BDkc6NjkINDJYCJws2hbIRRXx3NnBHhnkMSZkQDPId5aGPTldlggljMN9 bese8Rv1p7hrpB1gGw6iVb5S9nut4kJ3l9U7RF7Mf0DZUjFlbmRzdHJlYW0N CmVuZG9iag0KDQo4IDAgb2JqDQogIDg2Mw0KZW5kb2JqDQoNCjEwIDAgb2Jq DQo8PCAvTGVuZ3RoIDExIDAgUg0KICAgL0ZpbHRlciAvRmxhdGVEZWNvZGUN CiAgIC9MZW5ndGgxIDM0MTY4DQo+Pg0Kc3RyZWFtDQp4nOy9eXxV1dUwvPc+ 87nzzZ2TcE+mm+ECCckNIRDJCYQIRiBAwASNJCQXEiUDGRhsFVQURKtYJxxa qK1Dta2XBDGg1mit1vax0jqhrZW3xTrUfKUtIlVy866978mA2r59nvf74/t9 PxP22WvvvdYe1lp77bX2OdHe7r4oMqPtiEN6c3tT12fvvPp3hNB/IYSdzZt6 tb/f5s0E+DhC0ux1Xevbrz/0t30IKSkICW+u37B13ecLboogZD2FUHFZa7Sp 5YeXvWlHqLIA+pjZChVb49dIUG6FcmZre++WTp//J1C+CcqPbOhsbtqXs82D 0IJZUK5rb9rS9Tf7CRHKe6CsdTS1RxfxHwHughhC+SVdnT29b6K8UYR6P6Dt Xd3RLtvSnMUI9ckI2TuhDsMv/TEDKNIy4XhBlGRFNZktVpvd4UxyuT1enz+Q nJI6JailpWdkZoWyc3Lz0P8/f4QjKIWlh1AKH0Igt9ETYyneNnqCttGcfATM Sk0k46cf/Qi9iXOwhgbwZ8iLzmA/noEWIR59CtryGBpBdyAXqkV3YifKRB60 Ei3CPOCE0U343tFNox+i89C30f2jT+BrRh+B9lvQC+gMzOAPPEYlaAngr0RR 9CH3HqofvQfJaCcyoTloOfagJvQG/H4Cc7gN3Y5+ir85egZGdaFroL8yVIEq Rp8dPYvy0E38HuGY8ji6FT2JxdHm0TY0BaWj3SQ8+sbouyiE6tH30Y9gTmE8 xC9EaehydB3ai/3cCwDdgX6A4thMGrj5wjMw0iK0CnWgzWg3egT9EjtxjXBM ODn6jdH3kYiSUA7MqQ19iIvxYvIAbx6dO/o2uhgdRr+A9dLfIf5i/iHh4nj5 6HdGn0Nu9ARW8VP4WaFQuHnk6tHvjf4ENDKEZgBHlsA4a9G16Fn0Evob+jvZ NroNLUQrYOSf41Ss4RBw/A3iJ1eRq7hX0XRYbQPMtg/tQzGQyBH0JHoaePM7 dBy9h104GV+A1+Jb8d+JmbSQV7h7uYPcazzmfwj8zkBZwKNe9AA6BPv5ZfQK FqD/AlyDL8Od+C78HXycxMjH5FNe5q/lP+dHhFD8ePzz0SWjnyAfCqAL0RVo G/D2+2gAHUS/Rq+jv6N/oNPYjmfhVvw9HMPH8cdEIelkKekid5IHyI+5Jdyt 3LN8MT+Pv5x/mX9buF64UWqS4mcfjN8W/3H8N6NPjP4GdMcK/YdQFXD0atCK B9Az6FXo/S30Dvoj1R/ofw5ejS+FUXrwLnw7/jH+Of4N/ghWidhvOplDKmHU TtINfLqG3EZuh9Ffgd+j5G3yDvkL+YQTuHRuJreR+x4X4wa5o9yfeTsf4qfz M/il/Gp+FCRTKJwvrBAeFh4VnhNOimVii9glfiBdI+2Q/2skb+QPcRRvjcfi A6C7MmjSFcCJ76L7Qe8Pggx+CRz9Ncz4ODoFUgjgNJwN8y7FVbgaL8YX4Utw FF+Dd+Jv4734Xnw//gmsANZAJJh7mFSQFaSJRMkOspN8ixyE3yPkJfIGOUaG YeZeLoMLczO4Rdxq7mKuA9bQy13F7QDO3so9wr3Cvcq9z33ADYPUvPwUvo+/ gr+bf4g/yP9GuFBoh9/7hWeEIeE3wlnhrEjEgJgi5ouXiQ+Lf5REaaZUI90g vSb9Q+7CKTgPZq5NthbED3twCnmEuPhteBgqUjGPbLDyMMhhBeyKf6ByLg5y sdJ2mJub+PkkSinqPNho0oufRMX452ibSDiwxPxx1I9/T47zPyPnoddxI/bz D3Edwi9JGnoUrNEe8hR5Es9DB0kZWUXu4xB+Dz+M3gN934Jux5fjHvQoHsaz 8ZW4BG9DrxEPtwLvQGWj9xMeK3gRPolgBuhqvgVd+u+tIC5Fv0cfxr/LW/hv gn0aRHeCRH+E3sU/RJ9hYfRjsG4cWKMmsDI3gb5fh6jVa4B9tg32ox8syAbx FXSQnihSiTiXvwKdRP9EHwpHQKPmgSV9P97Gf5f/02jJ6DTYYbDL0MOw71rR +bBj3gMteRrKtHQJ7HQVbEkh7OoatBq1oCvB6t06Ghu9b/Ta0a2jnehXQPsZ noo/w/thRwwCRRn6Bfzegt7CN8I+PP9/dgrEW9AQ+gj7cBYuhP0wLGwS9giP CAeFnwovizOA2zvQvaDRfwRtVmEFzeg36CP0KZZBNn40FUVgvrNg7nVoA6nn nkbzcQB1wZ7NATs+z1hJD/RyDXDvPtjPT8PeOAl24hL0U3QME+yFFTXD+DL0 Uw18XgPYD4IEr8UDUNMCVjsP/QXWbcWzSC+Mp0NPd4LVGoI5/R79Gbg9yuY1 FexCJV4FfX2KLkItMMJMVIMPgAQOoVKwrJXcfwG/M7EdzcPp+AdA1wg71IpS UanwJ0zQ1PiS0VmkjXsazphRqN8Pp1cyOg9vhFnYYB0jyI2XouL4cpjDqwjp FbV6+dzzyubMLp1VUhwpKpxRkD992tRwXm5OdigrMyM9TQtOSU1JDvh9Xo/b leR02G1Wi9mkKrIkCjxHMJq6IKOqUYuFGmN8KGPhwmm0nNEEFU2TKhpjGlRV nYsT0xoZmnYupg6Y676AqScw9XFMbNfKUNm0qdqCDC32cmWGNohXL6sD+FuV GfVabJjBixm8h8EWgNPSgEBb4Gut1GK4UVsQq9rUuntBYyV0d8Ckzs+YH1Wn TUUHVBOAJoBi3oyuA9g7FzOAeBfMPkCQbIFJxQIZlQti/oxKOoMYl7WgqSVW s6xuQWVyWlr9tKkxPL85Y20MZcyL2cIMBc1nw8TE+TGJDaO10dWgG7UDU4d2 3zRoR2sbw+aWjJamS+piXFM9HcMRhnErY94rTvgmitC5c37dzsmtydzuBb42 jRZ3796pxYaW1U1uTaPP+nroA2hJVlXj7ioY+iZgYvUKDUYj19XXxfB1MKRG V0JXlVhfNGMBrWm8TIspGfMyWndf1giiCeyOoeVb0/oDAf3w6HEUWKDtrq3L SIuVJ2fUN1WmHHCh3cu3Dvh1zX9uy7SpB+yOBGMPWG0GYLZMBqLjbQxi6BSq Xj7OWUxnlLEIFCKmNWswk7oMWNMs+ojOQrubZwEa/NRjoIq1gETaYsr8xt32 2bSe0seELHuGtvsTBBqQMfzxuTVNRo2YZf8EUZDqybiqQfsYHAuHY3l5VEWk +SBTmONcVi6eNnXTIJmZ0WXXIAP2oRrgbVP97Hxgf1oaFfCNgzpaC4XY9mV1 ibKG1ib3Iz0/XB8jjbRlaKzFvZK2bB9rGSdvzABNPsgCAXdMDo3/s9k9SQta Z8ew5980RxPt1SsyqpetrtMW7G40eFtde04p0T5rvM2AYknz67hkYkAkmWOt oJSXjCPTQp05xmfBP5EpdUuMA6VkFViritkbFyae9Wpa2r+kGZTkSUSDoycp FcsmyIxZxmaHzy3POad8zuzMuzmYLx8i1bWrd+9Wz2mrAgO0e3dVhla1u3F3 0+Do9rUZmj1j92HyEHlod9eCxjGBDo4euTE5VnVTPSyiFc8GZSVo3oEMvGvZ AR3vWrG67jCEiNqu2rp+gsn8xnn1BzKhre4wuCI6qyXjtbSk0RKqxqDo/URm TcmHdYS2s1aeVbBy8yBGrE4eq8OoeZAk6uysDn6mgZtChS/AL5z6Epp3kOC4 KA2Scj0JCXycQ6rExzHyy6IQJ9xTOIQUcHZ9yBe2ny4bKVtiP1W2eKQMlQNs PwuPGQVpjjRHFjwwOBBnNW7orC6gz5HGD8FYLAp7BuIsCam44jCSRo/pSklp RMyBhzQ4OqQrOcURUYcHlI7pNWnZ0AaPXJTH5wk5ar55FioRys2XoctIlFsn tMrr1Q842wUiJrKCOVVReEnB4DhILvBPRIXnNUF0CYIoq3ogda5KhzAFUiNq FuE4kVcG8VO6VZSIwEMgJpu93gAaJE26KYhZeLAdc3iQZOpKUMEFynaFKEdI JuIBQ9EELPhNlzb7wsCDhsUj/tMNG081bPSNLFkQrfwzMKTMXlZetnjY4SzN LxsJh8t2CtPDO698fud0H80ke1nZzuefPyCS+bV1B5WIYomgcP2MAlwdM62o jk0B1TyMuNF4v8yrR0bjwKmzB0R+Fv2pxxsbwuwnLY2DX5yWxHHCM/Gfbh85 tDX+ApmDS/N++QJeHB8QjpzdTbSR4/Qu4C7wQHcA5xXUrZfLAi8KWZImF8jP yO/KfL68RyayjDg+C9RQQbJULi4Fh3k5B/pBApqpwERMvKIBYwtAioPkxgF1 xorE0qn8l9gbTgMABVg41QVYdMNGyDkB1jmjoMiR5k5j6S5ueGQOaRm5Tzhy Jv7AmZFb6dx2gvKV8HORHT2s59wlYMWKVwjrhD6By3fWWVutXU5eVWzmoJnc Yh41k3LzUjMxD5LNeq4kYaRyRFRzkGJXCpQuhVcC25z7nGSNc5vzMedRJ++0 oxDmBnGubiJkO94PPpjfUX4YpyA2/41li+3DdraEjacb/ItPIB9dQvlww8bu UvBycANq2IiqY16QSjFI5YBaOKseNaTR5cycWVTolUIZ6aLowPvj72Nh/uWV jfUXnX/enOX5fOiuyyuLP5le8Uj8b8CzRaMfQMQ1FyLRQrxRb5UCcoqQ6glc kLwwZVHW7+zvOpSZ/ir/RaF1/vWh60Pf9t8WeDBwOPnFwC+SzaJocXtEvydb zHXX+zeT68mD4uPiC6L5mchbdpKaWTjDMdWSqYenRzL19Bx4+FMjnZlnM0lm VSpV+AKrLXJeKkap9tRY6j9T+dTUqbgI6VBrQ0GY2so0PcVRnqYn2+HhC0TS Bknv47xktqhTgXwA2lgOzSwHjKmAoesu05QZITlXybHUB837zCRoxqNmbNat nog5sDSCI40g25sLMMZFuWlrvPhdL17qXePt9HJef1FbRUJ9NnYvHj61cbiB qlA4UTpBDcow6DeIAXZO+FRD+ARTqHBiu/Tnp+KN9cOJwmGUOTr0RHJqpDaz JZM0hOvp3oBNx1lB80D1YLOAAHE2lZXH4+ZcHm9aKDuULYoZ6aHiyMyZJTPB n6UyxKIoiW6Xp6gQqmYW4+ho+LevPDVYzSVnxT8y2SVu4Q8afvD0qnu//fML azqra/GlMz/KLKmrvHBBkd1E/jj9ntvrb3giPnjTdRemlPjlqqr+Xau/VZ2S paUsWzAn/ltnoS+7bM6qwlBJZhS4chVEiXtBG7LxnMMoF2TU4FDLBVE0u0WP OcJF5IgvklFJFsgLfJUZZo3Lz12hNOZuz92X+wPxIelB8+Pi4+ZY7tHc47lW lJufWwMNz+S+myvm6oGUSDmUt7NGQUrjpUCqB8TVr0pUrvoUXrI7HNnJKSmh bBUj0WYPOR366uJGB+50YMcgqdJtgeRQagrUdabgxhScAnUHs0KhbAybqB+h bKoENqWc5vpMmHc2oGbrFZDKIGVmR7L12edF8rNfyX43m7NlB7O3Z3MoW8su yB7N5rP9OX8qGxN9woyFjS0IFjQMNuM0mLeykYQlASNKf8uHy4cxCBVBApF2 h6lQcTgJtiBI1ctkC2EHnDyRbLYdGRgaA6/C3I1D6+4sqLr/kr77c1Lj76dm L5vTOj3+/pTymRWt0+Lv86Fbf1i7cmXtmksq947UkzXfnV628MY744RU3bt6 atWOu0fOwjapgB2cDTJzoRT8/cPIPnpGrzKV3q3cY7nT/rDwkPqk8qRlMCDL LryQnC9WqUunPGw5JB4KvKj+wvyGesx8RvrUYkmxpbh10Fa3bnVEbO5n3K+4 OTdj6JRyllu9kJNv6Wab1VljbbQSq8+JoeGQPzmCi5yI4qRqEZan5yby8LRE 7kthuW6Drb2fenV2mPYapxPkPsCbnD4q/0yThNJwvjttqRVbA/lT1kzpnLJv Cj/FlibrFltE9qcaOzO8eJiZddiQw7AdwenSXT49x1Xu06fY4AHmwEftBhVg ffkItB9GTpgEYDjpZADJaZgNmvePoYLcmdAZAYIGECtt99IsNqCoc1mxIq08 jCj+CbqbG9jwVh24ZKWDWunwVh2YhVin7IgFdSrDjiJqszeihjCG/ZShZYeK 7aioEHFpHtjZM5OoUkiil3yGfTM/fCz+l+vasOvVYewUR3TumqZ5q7O5Lasu KSvDeHn+Pd97/NZ3IPAPx1+MP33ljQvxhiu2zZ/fQ08sBfbvLD6EzCRbn4FM WEUiUSVBSUYeMoV3CAHJpUxRHWazM8yFxQxTKVcqLuQWinu5vaJipTLaMvX8 iIpMPC/wiknlzckowHsEl+JX3WZzBsrhs4VpSo6abZ4BDs9cpQqdT84XFkqL lM1oC79Z2KJsUTebd6Jd/E5hl7JL3Wl+C73Fvy68rrylvm7+CH3EnxBOKB+p J8z/RP/kTwtnpNPKP9XT5mnC4OirupI8O8KH4KEMjr7NSiotmcfaEC2JVHr+ 2REO8icgN+nwMBwWGVstrF1JY+26GwCTTksmkUNY4rGoIDWxhx1ObykIiW7g 0uSDz5l4QRscXTwgqgrkF+qFHDJrQMWZwdngzZygmiRFFmVJEsAtIwSLZhUc O6TmW8thO4CPJlco2Io04Hk7MkHSEYetBzXstzx/GAcS53rAv3gk4BsZCfhH fMwla4DJMFti2BR7GZsQ/HOwJ3KwWYIPRlUKJywTaFIYUeU7aNItpbDiM/2W UljwmUOWUpNupjUn+820hmZQOt5voqXjB0ylyLBu4XrqQ1A3LYn+w2kch+vj Mex48QlsO/Ar7I4/Gv/7Ewf50MhCMkjT52+TR0dWwtZdDhbnHrA4FuRHd+kL P8Dvy58mfermXyQfCMTpF/wKqbevSlrlqffdRfaKe+W7zIPK6+R3wu+V183v C++LH1jsD8m/Iv8l/kx+wSz0yTeIO2TOwU4Dk5daAxcvuUqlQGNyVzJJtqYh f6Ausfvp5t94ejHd+eXDwJKNDcCK+XW60mZf51znafPxuAHcINyQFHGC9UVu F8pIzwxl0eNzZuI8Xb575L6/4Uj8pY+/Hf90N9bu7Oi4446OjjtJ+k1Y3B1/ 8a9/i/9sx+jD33344f33Pfww3VU3gI+6BnxUE/oHdX7fGbA4ypl2XemfFpE4 O5ckZivrxMfUZ9RfKL9S31bVFVwjRyyST6kSL5I3icIh5V1+mD/LfyIKS6Ql 8jrxSv4m/l7+PuEe8R7pHlkN8k4xzIeFPDFPypPzLdV8taDCua+oiqwKqgIx gQl8YxoUmUyypHKqauIHSbseEPLl0qCEpaiFmEJ4O8JBmLDfXP4N4yyjbrDf fnqjD8wlVa6xCKC8DLR/p3yl/Xm5bMxj4UZ/0Q9bJeHwNzSAteoGrwWcZAdO w/BPctyA/XgRXh2/A18X/038k2vBkz+NN8W/OXIpfueG+I9gaB+EU38WXkUe NKgXzuRxHq/ZNUc9v90nyPwzPuL2OIjL6XFYk2zIbk3CyE5cimwz4TWmUXDm qfBVETtsHjzqwR7mGUAkik9C12KSS1WKyuWlco3MyTn2fMcaB3EMYl63WJNC xLUG7fcMeYiHnkqKOeLxe7ccJm2JbRcGRtA48GxD2akGf8KZppEApHJ4lBba 4MfwypKKqP815kK73UXuDGBBhu++0rv7tvSE5s89r/i3v42/fx8fqrl+x4rM 5+2ly6rfOfsEt4hGkneArpwBXbGhZLRZzxKFw67DPu58Aa8X3oDN4ciyWK0o 2U7jGRuSPdmPgeyYwTJBaElu0j3B1ILUxtSu1O2pQqrdNjm0SZkc2iyGbRDe SDfCWGDDolzqUzaAxDQvOJUu6jlmZPgJ6D5VfvBB7sC/w9blVz2y9q4ll730 7P2PbZp/6cLi/cIRT9o7j+0cbHO4R97kn4s3Tl9bUdNqUWHg2vgyvpHFB/l4 ib52c+rOVOI0W7pmXG/ZPoPXcAbJ4ApwESnidDyfzOcuttW76rNW5a6Cw+9y 2xnHmSTnHEuRZ05O0dRqS6WnOqdy6knziFe9GTxyk9liyjNbsq0er3uaxez1 8L5M6lM8znwK5jpYHezYHTCZE3lOXsKlyMhK5DMiCddCcSczt36NQK1I0JZN M6s6jSqQyS35/GJerikU8NF4S/H7A4FbZuAZ4DgO6ioqykxz+gvqygwDc4qZ mITvd4KyFyxN+cgpwykc2yuITY4N3g/KxhwCTE8U6guW0iTJ9rJJFsrSZmtz tWWtz10XbssXqZHyCuAcGl59Mbj9hkvgLU5zuKwkQ4MwIGmS3dqKK+TUnFUd JVlJlquG3rhyLcbP/Hw7luZ2PXlL/O9/PHtt4/qbd7VGr63KnuWekuaZkXHp vT96/JbXsQkHfnzH2fOfOnJZ2eGbreTaH37ne999YP93QLZ3IiQ8BbrqRmno jH5NqW2R7SLpMtNl5keUh6z7Mw5ZjymqKIuqV/aoM61V1iobrEmByblsLvtM 60zb+bY+61b7q6oJjn3/plQ48P3Xp4qKx6WAm7jC2mfdYb3d+n2rYNUsZpfF YraZ3RavJyvJ7sKNrv0u4nIhLY1uBdgUbiRb6bVHNrLYLcTyWnL2fjEmDolH RV7c2ZWBtYwC0LU09+QdkT6jeWJHsEB5+FTD8JiJmwj32Ym6c3q4wQr2DjsM fx2OiY0NdLMUsr0ieTzepDRuOsnIcDgmdkzGnaTzL69vf+7ZxisvG4h/943u 2kvXlf3u9cvKli7MPPi+cGTpL6954M2UWdc/Gv8jLn+0Pm3kPm5JZt28Cy42 C/TsWAlnZTnsHz/6X/qyOlu9s97Tamtztnmu9G3130XuMr9gf8H3pv0N34fi h/KHSR+6z4hJs5JmuS9wXuCp8tWb28zSbGeJp8THbRY223YK19tu8D/sfMhz 2HnIwzy2AV9yhOaPO10Ra5GFOUdTIiy3OSKWI5hHKmwCp8OEdEBFOuChoj0Q /R7BGPHQpHklTGtxGsq3UMCScMKTpTTXOQcvdbrDp4bDCLZDwwmIg0dOhcOQ J8wOKLrAQhsWq84soW5uOnJQlfbwM+J/sTYvbbty2+U169zYFT718ofxv2DP 8HPvkY8LV9Te+sjT913cmf/T53AI81jCWQ9R3pnAlq4Gb9aEk3W3kBPIj0j0 IdKHTB9wCB8bgJynJkALzI7cA/4dZ5Jl1WxyYzdxcgEloKajaaYXTWbYqid1 D8QoKhJMLuQ3ZaE8UwTNNu1EiuE+qthiZn2ZFG+EB3cai9RZLAdXsdTwE3Wn Cam8CRw/6gECrJRSXuu+lJyIyRK0FFh0C28BZ9CulqtL4aAeJAW6iSelJlCD pTzHHyEFCI9u123mYoQ1rGMO+83P7/eF/VSRw77Fww1geBr8CeeQlpmJp2e3 sxTDFOjhvDHcQCOJxG0beHBeel0APhx+Il6Ls38x2yta7b/EaXHg3sgfH1/g mTaNTPn8bcpTK9jz5cDTJBw56MwRcBI4hbrPDBGWB8IsiT5E+hA8UEfoyoLA V5AlbzFZRTtBSSKfRHjwFemB3GjH9kH8GDDFZsm35iDNXeBudHMngfksEAxF aK47U6ZE3MATvpTTff7INo5efGXrCmEl2P+05MSlSE+ZGUlsb7+L8oSxZPGI H56UN4lLzHB4Y/di+ymwzcMN+QnOAF8Su5q5zZKVWV6DPw3VMfuK6tjsZavr +nk7OjIKvsToyQOcHbNbSxbvCaMf6Fbw6pLsSX54OH3lEI+cHIACzfuhnOir PuEqS1YOzHU2U3MrxGFncEb8hvlZ8y/aVrNsiX9e8dpL/cB4K/n7WXK4Ye15 6Y7fW3rqKfdvG31fyASL60e79VmSLCmSHYyrcr58viJdpKyy32m/y7HXfa/n IfsTnjfd74mnRZPFbMaISFlJitmkWV6BjQmWT0/Xk2uSG5O5ruTtyURLLkje nzyUzCdjoiHNX+Af8nN+aiADM/omuwwNG7tPNyQuxoeZkWQxaRKcN14Whc4s BkfHDmdPeghMX/FtOMeUdMs3r9oewDkFVx/7yW/fusqVCi7fn5+etbp9/Z0/ 4cJn4/Ezb99Z33TvyqtO0/UVgLWzg7XLI8/pQ6JDzJCzvQ5vxl7nXtdd2Xfk KZKrykWcT1oOW19Mey/jjOV0uphrWWmJWu4w3eV8KP2wWarI0DMrQ+vTW0I7 nTtd16dfm6mUhBaIVaYLLEttVWnz0qX0zOxQibk4rTi9OKM4UxJVwaGk+SzZ 5vT09AwpM12f2mPe4trq3pTbl7fLvSPvHvcdeQfTD2ZYtuNbvDf57s77YV5s quhN8+hpGRGPnhKMBD34XXA2i+S0mqxbskiW7kuNZAXopaLudajlNVNxwVSc PxVPnZJWAApfBIbSuGtiOaAkfBB6We4PbxmkLD8L2sJuEOkFbneY+Wqn6M3S MEoYG71YxFjEHhxKn5lWlVaL670tuM17GqvYS/hAWjrJSbKYSU5gDY/5qhxT TQAHqpIk8FbhH3U0xlLDxuTDKH30V9Q3ShtM5OmwqwemZNLy8YFgZqLsD7Cy ngzA5RY8M70qfa/l9vTn019LF9PSzRaeDyDD+0JF1A8b8E4rx8blByunZ0Vo rqcGUiIIF4DxqsF8I96OT2IIru1QagTzTTGTPICJsb4Y8XgNf5IndAkeHbr2 FHl16NerQ6devbgk4qU3xF49Kxce0K/NG2SXsbx3ZUBPz4zYArgmMBogxuI3 UkPAfk6EafFU2Livo/cxlBlGbJvw5TfCT0MD2+KZoy/pislZbsuBB/DhYwiV zS5zKQUhRgYOfTQWHMNerwe/LSnLw9yz4kh2KBuUDqICep8nJK5q3LBnePpN Ab2wLcABZ0dze0mWy70o/qOLr3r7vbdfy4l/6lhT11mgpYTws/V1p/761gjO Dy9fmZOSr7ldjuq5q+7e/dTNN86YOy/oyZjiTll3QfX13/5tDGzfbbCVfgRW gr752nwYKcDxclAyXalRyHYlpgwpR5W/KkJQaVS2KfuhQuBECQk8Z0NYR0fR caBsgFhRFESJV4kEZyrTz7TMCO+XyxOObth4QcbiB/CS2CsRu3E13R1OolEf pNuwP/4+9vOHMB8/+/kFfAiOEYxuhZO5Hva5B+3TfVKSN2m13CrzgzyOyBF7 pVxp+9AuiNT3TnVIVotoNpkweCE45EG6lhl5DAwwdALeOMzKAzLe49vvI12+ kz7yVx/2qaaQ2UrvdMFjZNeGQLLfjE9CxOD3GrMHmU96QQL7i1WMTIS3w4Z/ lzb5wtXBLmanEDdfH38/c1npot4wfTty46sN9ywNkik/is6q2dEfD/Kh+w7O b93xDWrRmsBiXwrxbAC9oS+5XrnBdYNnH9orvqi8xr1m+oRTspQcc44l15Xr 6RP6lOsFWUqSvN4krzeX5HFZgpQj3C3cpbzE/dwklOOlmODldvqp7knqwVLb 4UvEMSqYjkG8Wvf6pvGyVbc6I9bqNTa81IZtutsXsQ3iHD3dOU3lbH+1rkJ/ RayrQEEKTnFn75ewTQpKBRJHI8iB5KuMMHHjOTelI3SnnEj4bAA0MP5AkI8F kc/QqJ9Gg8aEdosOOz0O+HIcnBd/+eP47+O78BU4gi0PtxTGfxd4YNP3f/WL /ZseIckXn/wQ34JX4w58x75LY1XdOz6Kfxb/6OM7Kee+TXUEtNiD+vWwDQdx KQ0T7fPwPMcf8D+xIgkeIZPUOVodAsYkyeVwJnEugm1MbThJUVWXW/UgZFJD ssLURsGjClb+ldogV8jjHtcXN6ZOyLn68hXKklCXYfAavOzVjFyWeLWGHQlF Oee+3oEf3fV0031LU+Pva8vOq+ooioP/P/LevoVdu24ZuZXMeGh1ceUN1498 DIsG8d4Y38Dfxd4epqB79OmzkhYmEWeEK7WUJkWSK7lFlkVJlcn/TFZWiavU eucqzypffcpp6Z/JMmzcAA1fBclFeeExmew2qzdNDnRNwVMcuVarLWS3Y/bm sAttp75SannCSQeJl8GWsJ8YuyRLBK9ja6JR6DpxndrmXOdZ52tLYVFoUuJ9 IVUAMGTZjjQ8Kea8EYtFP7nsMCbxs4frblkKm8Vz87q111zfvH4XbJKalvgf 4iPx0/G3qlaOfMgdHnj0OwMP3b8PZB8c/YDcKnwH/JyX9VxwSXCGmmubbb3A Wm+T/G7k4zxu5HUmubDXSVzYxymSKpl99MCwIe9+b8zLNUI25OW8g5jvh4CB vipAbvoFQK9uNZuUfDUfoXy8BnYBvQDK8XEhr3Olu9y1z/WYi2t0bXftcR11 nXQJyGV3aa4CFw+hzJb9Yy94qmMl4BLOYW+zXaNDs+oTt0PgJ9lPsduhYfbl AKCeAKfSUWTcDjVgd4bDxU4Fr2g4SY6M4qLiLAe5YsiUnZJ9gW/tNy+8otSk XH01DvCh4/Haa8IpyW/nFS1bMOMO/MrxV38QvwH4sxci7wz61hv/WrcqnCj7 Oa/MO2XCQUiDBpwmdr84cHFD4hY7b0VthCuUZJckyZxMiMQpPCEKFHgdcHgd 2vlC8RUBC9Q59OumGlOjiesybTeR/aYhE0m8KZcVo1Oa69YVKyJKIYumh+DA SLw8n3AX2euvhjGPEUpst7AgCCWiafjZeeXzE5eHx3XFmh2RNXiwu3lwh2Sd fUCQOJDnM6zth0zF8nZTMVvYeYHpEXkFPATOwxVyOsdXcdfJe+T9cr98ghOf 516R35Y5jcuXI9wcean8bW6fvJ97TI5xz8imxIcZRcURohexDzOO65b8wgjR 6ENyFUPNXXDoTY+QWngw7KopGpTgIRNJ8hHOK00l2dIcUiQtIbp0CVklKS6S LC0mC6R7pEelX5G3yAfkfemfxJRNcqQLpC3SLulHRASnuXvsJWE4jBoMFwR2 UxHsH3rOYMderJE6nBR/c+QAuMzTuFc/q+KeOltJLeNN8DjIzvdOGnoMDRRG IoJxq0VzvdzljSBBF2qE7cJxQQgKjUKXcFLgtwug74RDoCdvYYRi9KQfomcJ FSI993nUwc/YN6bl4zaOufl0ivQu9yacIxz5rCrxVxjCCnqvjefo33Pwyeoy frXKPyo8KD2q/MD0O/yaJF5n2otv5+4R7pLuUW43PYx/wCkB7JZycEiqx6uk 67jdwm5FieA5EvGrGp+vVvIXqherO/ib1Fv5fep+/jX+D6qlhJ+l3sbfq77I v6Qe5SWVKKJJ4mTRxHOygDBRBKTIHKcR4D4URJNJQ4ILZicKAkeIrCgmJAzi p54Q9SR3RKym38cMyAELdwQ/hQi4rFBLqk30+shkhI9m+gkMC6khgj4VHgbw dAJC+QkXAR7nfvtCN3lCmx9XNWc2vVU4PpDIf/mE4oioM+ExpszsohW8S9Q9 Aydux+k//El8NhyHIQjsL4rPgtK98SfjR8gIeTqei98cmTVixZ/H2b3Q3bC6 nzHe36oHZBE7naoKa+X48Vt/RVZUeRA/oYclETa+yNGPhlSXIKiqwnGiyimc bAJs+jIKE/ZeAFww0tIvLJQh051SQLMUWIiFmCbfmZkn35n5qYPgSzgI41zx O0vzE1eZ9BWBAMzhr7Q/zwD6vmCnDMfk8xx9Gm8OHlc0k4Xu+V/2y9mUQ5Q/ cNj4Q2K2soffK+7nY/wQL+0QH+Y/4E8LvEI5W7I8YYcyAcgSz1N7ueu5u7m7 lXvUR7gj3Euc+ix3lDurcuep8zjSvZFed2xsSITr4ugH1EaKgxC2J9lM5XyB xQMPs6uc18C7h5kcHbD5E7nVm8gBg+WAxHIDr9+aVG68EcNjb8Umv/G4G+eQ VfjmkWOkKn51vP0kHPh95MaRn5+9msQ+iS+gMf24t76C7WY9l/rqsHfJdiEm DAlHhb8mtvA2YT9UCOCYc+AMcyGMxrxy5Oe/5JUbfnhRwgc3diwbC/uhg0zd TWZBNyH6rQyVLg+drN809tkXKl88zL5vosTUhaceSS1E503s3UQK2qNPc9aL 9eOex17pbuWMonRN2T6FzOYi5tnuiP8CrtJ8gbvSf7eiuJhDYgqw89ckWSHS QKo312oJMUfEZkOBW8A7safJ/tTxm/TEPfrwSNmfE3HG8LhXzu7DxbbJnkha WrFxYegsKvRSN8Q74YfwTfHPKw6sfiL+efy5/muwf8SZX3lF064d61t23ndx Pc7GMrZi/+3EfrbrkQs7HvjBE9/bl4hSROAcMhOfbjJxITlk4nh69zS6XVdS ZkdUbfacCNNFI9d/kDIdauEhwg78k/KxyvPghyaRFN6uBNUMMpXXwPVYT1r5 qHKZupls4X+gPKI+rhxRTyufqZ59/B5ln/qC8pL6JjnGv6G8pb5PPuDfUz5S LZuVLeq15Cb+WuUmdQ+R6kxRchm/XmlVN5GtvFRJqvlKpVq9SL5IqVMln5pv jZDZfESZo5ZbJY6YeVFRVDcJ8F5FMu4PgoTnVEUwS1KhaDUXIsTZOSLXyJaI iT7YKq0megbDgWzSE6fyfbqdAiaZwxCZE0lFMt355WMvw+l9Gc4ftr82TCuS B0fn6NNgFI0HG1zI8S6O44lJVQs5AiB4FBxnBk+EvQiX5CC9nMKWAfpl/RHQ TiHhbbAjzQsuilAo6dI2GctP0xvAp02ayUwGySzdCUcR9WMQ9WNQYRACPdqN hXoj4NQOh8P2sv/HXhbw20c2jmwsC/js4I9Ahf3ExvGX5wlTNcmaG18tJq0A eyHTF98a/USxgf0kjmsE9oSe1zgtsd8dt+InsYol/FR8OP5O/E/xP8DB7eM+ +KyKv+bzq2iCPXRefJn0gvAa+yux7+oVSrKUJZZ6szylnsWi31dyHvFVzs3I XJiVgxwFvgqUkVktNM25BRU1WXD11WlSpojU8CXuiqsDAbdasBAvPIJjKAdf rvsKmhxz6bedENbVzL06dW1Jk+JfetmGSS+lIJI7BQD7YGDYPlxeTjeU/RT9 lBP+YXb7mfhmIBHbZRWJkpimZRJw7TPTCnmn2yWRNPDxE5+YldBXnCVp3Ni3 Zc7iCISAPHG7nHxRYSYe++LM2IKi+LfXW14Zjj8aPxTXPgI+/RrnnsW7XvnO z+P/taLWuumeB3+3Y/9n/Sv9WL7L6rUXXLjuqvh98Wfjf4vvfOZ1fPWZv+K6 swXrLywtDGUVL26rWfXtC5J+1bPjXTyAEVio9/7xfPyuN0Z/HT87e1b3ez/9 y3Mf7+ocKap0+f2zL8TohtO4+p1451uvxh/cdx3Rtm1JcYXP+yi6cet1p6ld 2wl27XbDrn2Hfu1zRp9hKi1JPj+ZOGl0lbBwn0piMT/HMiepOHkBX22pTlqQ fDsYPdVsBZ6jyRFXkslkA+tmRFz2XLDVNmrlzPiL8VbCun0p2mIv/cDGmWi0 lbBwAo21mDUHtjuNYMudNNnI7cT+a/qfi8dHDl98QHdGFm1tuHbH+uj1cOKc vD3+fvyf8ZPxty+uv4/kPbC0a9+jh773HepH3A/7PiQMIQWt0pXLyTfIjYQj PMx2YA2LBi59QlYEjMwKehLXwdwxadAtAuKDvAaHMs/71SP4IbwfjfkEp8c+ cTvVMMz0KC3NIUrFMzNLirhQ/P17ftOBScEJPmPPgtHMl66nM/gWcH8FH4I4 /z7de5FjveNOgVNEv1hGyhzVpNrxPpFYTO/gTR6kul0uVRGTXCG3G1GeWj0s tE+87v83N0KKPB7ay/gk2JB/HdonguAv3AQ1JI6XUIhecbsmbru5JbOfbrv8 kQuxP7i8fGF3HvbvW7n20kfuJPvjvuPROUv7TuChxJuTIoR4M3A6FZfrax73 HQocTv4l/6LvqO+o/2hAnp88P2V+6ir/vfwdvkf4B1NkMaChHLEksJCf75vv nx+QM32Z/swA5wnxq/hdvvuS70u5L/WRlEdSZSf9AlZLnZG6KXVH6p7UN1Jl 9nmsx+WOpBK72ZZqhwOeufg6jdPAqDo9EfDlvjdAsBkUc5WeETTnm4lZh3rz g0mCcszjwUvpDVvQdsy+mfinvPpcwo4wM7KxjF6dofKR8MYTEOaGGzaWMftR FE7clKaODvU7Sukc+m0s0632Ul62lwqyA3KHcU7UG+eQSUn2J5PkJEz/yjBh ixrYByTVy+qeRsmjx1EKpNTR48Y34g0NECHNdLLX3kzvpayZmUWF7BWsyIsS bz6bbd//8U/Ds6P1da1y/AOwKC+8deb8xUXx0+d7sBD//Has/O5A+UUrL41e 9o2UD3750U+aB9ZWnKoJUSktHn2fTwYp5aK39MKd7pfc5BspN6aQB7kfCg+5 DnFHhEOut33v+GWPC3/L8y0vSVMtcBB6kzxpQYvdrA7iTN281IJ1yy3gOVuw ZxAT3RZMyk8iSZS9SQ8mC+DxrHrcDvuHsGvVQqjmH8y2xMxDIAOzx35sW/CW 4L7gY8FngkLwuHRsaSbODIQ9x7yb8THkzxuTRcKm09cCDcOO0vwGQyD0QYsb 2ZelibdaBleZS0g/UGEX0wnuSSWecTbOJWDRgY8SfZ9Nv3tajO2W7mUXbe5e PrM62L2lbtHCdab4SHL7z7a+cuX6V6+6K/7n374Y/wxfl9basaPrsm+63+Pa LrqgrqVx6nX7Lt6xYdezPclPXfds/OR7wFf6XctJ9g3UHv08WeAlOUt0BgVc IDwmEEFQEp/oq0qWCcmSWM2RhSrENiYWgugWznLuV/rmr/pKv+xU4g82aGIc MF7NDfWnloIPsb0/wLIDSex7uK/6ij/NfQdffvZDcnxE44rol/xPfhrf+CnM 3gyzb2RvkvfqN+ZIv+DJXukw/j1+XTppEWQpwPtE2KtolrwQ1+Nv4j5JDeGw NBPPlqrwBdJe0xnxjKRk8SEpT43ws9X5/BL1Z7x8oVrL16stfLu6BV+p3s7f KR1RX+d/r55VLRwvQRjnASXJU4v4crWKV9xga2erS9TL1Yf4JyAQPs0rEn3J 6PTRCPPYgNvLIk7dbXZEMK9KPP3sEDKZxcbQcih3WmSUua/HdZsnM8KFJuJl o/kksJw2e6HZFJoUQ4tGDE3a+8UihX45ZpKjSy37LMdBNhytJkUmWu08mfhA NxFSRCfeTG9kYaJ/8XjAeG4YHd445nsloLFvYbyl4yG1ksYWmPjEbOyDRoih u2kg3V2E2ZeImH6HaMbb4rfii556AV8Q34tviD907G2SQbj473FmXBn5DV4U f4Ke+7Dh+UrY6yqyoHf1UrNmKVXMfnPYvMJ8ufmPZnHYgkXew2fxOZaFlost D1mesLxgUTCRkVm0SIJqskjIbLZYBvFP9EDCuaWuNnCE8CqSdMuQ5SgUnsQ5 4CUTfPAQ4nkggHOr7qBwi4pVahycdmmf9IzESQFbOdlGCPFbj+AL8UJ2op7Y yLy2BnaolttPlY00lCUcNeNtNWUdja7Hrx500zTzeebF5pfN75gFlDCk9F0/ KHcxLnLQb9GwA5OrRh4m3/z40CHwCR7D2ae575+99NP4W2QK/iRuYjc75M/r NzsyPlljK/tE9svsL4zv/1PZxH85Ahl+LP1mGI/9CTZC0tz4EjR/4o+yv/BH ynkiVAkvQvelwPs/obu4VLST70GLpFR0FeQVYilSoH45wDeQR5BPWIXugHIt 0NwJdSshmSBZoXwb5AXQz23QfiuUmyD/NqQbgS4I5b3QdhPQ0/HupngGbq34 CLpVehmdBzAd+37IvwV5EaTFbLwe9l9yoD8z0T/QP3AFHiBHuNv5e4SXxQXi 76SLpZ/JB5RmEOCjpstMb1uutPzaOt963NZo+4O9w9HuOODsTKpN2p30Q1ea u9rj9tzmec270Jfse9EfCjgC32VcCaOlib8bg6cd5aOVEGsusXfCAU1r1/BX IPqXa4zR7MkxbqqsxDEq8GEMmEN12G7APHLhVgMWkA9/04BFgG83YAk9j39k wDIKkS4DVtBucqcBq/xznGbAJrRW+qMBm9E6udKALeJB+REDtqJLbJeOy3ub 7YgBg7jtpQZMEG+fa8AcmmqfZ8A8Uu0dBiwgs32LAYsA7zBgCa217zFgGSXZ /27AClrgEAxYJU2OCwzYhGYkPTr+X4opSvq9AVu41S6bAVvRdG8bzATzlOtW 710GzKOA9wEGC1Cvep8xYB55vC8xWIR60fuuAfPI6X2PwRKVi/dTAwZZeEcZ DNsfmX1JBswjny/IYIXK11diwCBff7EBQz/+cgMG+frPN2Do07/PgEG+/gED Bvn6f2XAIF//nwwY5Bt4yIBBvoGXDRjkm3yRAYN8Nb8Bg3y1bxgwyFf7XwYM 8s2+g8H0q05r9t8MGHiVnVijCeqdOX4D5tGUnDCDzXQtOYsMGOafs4zBVqr5 OVED5lFKTh+D7ayfWw2Y9vN9BidRnuc8a8DA85wXGeyi88l5y4BhPjnvM9gN 9a5cbMA80nLdDPZQ/NxiAwb83PkM9jP8BgOm+BsZnEx1IPdWAwYdyL2Xwal0 PrkHDBjmk/sEg4MM/yUDpvivMjiT6kDuhwYMOpD7CYPzKH/yLAYM/MlLzHMa tQR5uQbMj8Ey4/84DPPPY/ojs3XlLTNgWr+GwuYE/lYDpvU7Gczkkvc9A6bj /hDVoq2oC0XROtSEmiHX0A8h1aJWBi9GnagDUq+BpYGl70TdANNnE9S3MQwN ajYA/XSAKll90/9lT/njM9PQCmjZgPrGcXqgbhHkifFmoFL4LUDTDKiQ1VYA xQbIlwPNephDL6NaDv31QOpGm+DZAljd0N4EmPPYGC1fmufsSTjaONZstIr1 0jM+6yIYtQB+IYSDPtpgbt3Q0gNpHfSV+5W9/Ks+JnCnTZpX7aT6nzDOUr61 QB/tkHejy6GOjvY/57kGtVHgVhvMqZfNjfJIgzLF6TV6XQny0FANo9fg1KTj LYbnUhh7HeN9E+BTuij0Srm9mVHS3qZ/xZwScu6EcemcugB367/EijL9onib 2azWj4/bZmjvNCblTrTWmPUS1tLKuNgEs5k6Pvdu1tLGNHUFPPvYrBMSSWjV LNCl+WwmvYzLY3zrhrlogNVk6GJCo9oY71uYhlGd62BjTZZ7s9FXE5sbpWxn PdJ5t8L47azHBPc1NusmNl6zIY1EC511jyGPJrbGBN3Wcfm3GdreZUgwynjT w7QxsboxCTUZ8+9jo2lshMmzGpM85Q0tb2Z9t07SBorbyfpKjD1Wn+B2r8GR ZkNTe76E1wt9RhlX2iBP9N1s1PQxTlONmtDpTrZzuxlHNzB6OlMqz3aDamyE Zka/yRi1zVhpYj/SHia4sA4waW+J2gm+thnc7TRW0sbw+1hpQqo9TEs3sNl9 tU6M2dae8bXQtnbW30Qf1F5cbsy2yeB/M7N6mrFLx3jWwsZez2oT9HSHtRky bGX7rsvQkU540h29yeB2oocJa9/EZJXQDo3xsNlYfxuT2gaG08X2XkIbOxhl YiWTtbttXLPozt9iSKadzYbq5iZjbyXszobxebSz0oT29n7hROr5wvqajTHW sh76GKdbztHNKNoI9WOcpbrdPL7CdUy3NaYDWxhve5je9Y7bk4TU6dwT+73X sBqJ3dRjaNmE9Uy0tjOJNKErGH1i1rTfZtY6oWmJ0VsYt7rYLtk6voqxsTuY zaTtTYwT3cYYdA8luNjL6MdmPNZ7F9OhdmY3x+Y2nZ19vdA2G87UfOiX/k5n WJMt7HRmndoBo5XtpQ0AtQPUwSQUZaUetIbpQELi08cx/98dYTPTmARudNIo S8DS18K5XwVpPmgehZdCLT0BquB5IatfADUr4El183w4CRbA72JWWwsxv8pS LdOmnq/QNW28PrFPEhztMng+oaP/2Sk2IZkxizwm57WsdSvg942P2Txu2xL6 PHEeTbaWCcsxYUcT+7fNsJk9xp5ez3qJjttEulvrjdHo7t5k2NK146dRYsze f8OZMdu5edw6RY0dFx3X6W5mP3qN/bzO0Mev4tfYLqQci07qZWIXf3m8FuME pBq4llnGxKzXGpLpMHr+Kglls1Wdy6mERf6yVnx55DHbRq1YE/NFm2DUDQa3 ewwb8q/GptxfCTUTdnbrl2QRNbyMyT5Xwno3sRl1Mc62GZ7OfyJzzdDFjkm2 bWxcaklaGKfbJp0i3ZN85anj2N2T9Hbi7P73nKKza2f9j+lV5zn9bWbyv5xJ c7IfOmYfJzA7ATfhofYxjtP+W8fXk5jXZO1uNyxqgv+JXdVl6MeE5T1Xh/7d iib0YxFb+5clN+Z70TMnanhoidUk/L1mJtWOL8ig+wv8nui5h3mrfczrT5xD m5hvtBlN9q7+z9If66/b8P/ajJjnq7y4L8sxwa0Jj7WZ9fnlfTwmsaYv8Hrd f2u2E1z+8gjnnvfnzihqeLG9cPaM9UDjkwqUiARywIePoBKIvzR4zoDSNIiv IizKorcjK1G1gVkArTOgJWLAJRCNlTCqmagYYgGaaO//vbPuf34yjrXlf4F7 4+dh7dau6Lqm5qj2Q622Naot7uzo7IUqbX5nd1dnd1NvW2eH1rWhebpW2dTb 9H9AyqedaSs6N/TRmh5tUQfQzSgtLZgGj8LpWsWGDdrytvWtvT3a8mhPtHtT tKWiu61pw7zODS1jfc5mNRqtmr0q2t1Duy6aXlCg5Sxua+7u7Olc15s7gTIZ g9VOY33VMvhhrba7qSXa3tR9uda57t/OXOuOrm/r6Y12R1u0tg6tF1BXrtBq mnq1kFa7WFu6bt10ramjRYtu6IlubgW06eM9wZo713c3dbVunVwV1Sq7mza3 dayntG3A3mna8s610PWStubWzg1NPVNp791tzW1N2oqmvo4WWAiwalbh/M6O 3mg7nVv3Vq2nCbgIjGpbp7VEe9rWd0zVEmtvBqymNmhs7+yOaq197U0dMH2t ubWpu6kZlgGFtuYeWEdThwZtW+n624DtXbDAaHO0p6cThqMLaoL++5pbtTaj K7r4vo6otrmtt5Wxob2zs4VSUxim3QsTaQam9ozV9W6OdvS2RQG7GYC+7q3T Ncbpzk3R7iaQd293tKm3HZooQXMfyLyHDkblGO1mU1jXt2EDgGyuMHx7JwzS 1tHS19PLltrTu3VDdDInqLb20FGi3e1tHQyju/Ny6LYJ5t/cBwMlBNjS1rS+ k7ZvbgWea63RDV3AkU5tfdumKENgat+kbQB2aO1R4F1HWzOgN3V1RYGNHc1R GCTB7jbKLC26BRbTHt2wVYO19YDubKB9tLdtYOztNTZSjzFeM1CsjWp9PaBS jJvRjX10sn3NlP/auk5YMvQIi+rtpXoCS++Ogtx7QTVATD3AMqaeUGxvWt90 RVsHdB3tbZ6aYBqQt7T1dG1o2kqHoNQd0c09XU1dMDVAaYEp9rb10I4peld3 Z3sn6216a29v1+z8/M2bN09vNxR2enNne35rb/uG/PZe+t9Vz2/vWdNEFz6d Vv6HBJujG6A2ykiWLK1dVLVofkXtoqVLtKVV2oWL5i9YsmKBVnH+8gULFi9Y UmtRLWptK7B1jGuUxVQmMFFYQS/j6FdsMbYYqsh0zWu3als7+yhlM9U24DPb Rwm1BOVgOgryhe3XAehN67ujUaqJ07V6IGttAjXoXEu3EVD2njMZqp2bqTpF QXBRyunuaHMvyHkd8HFiXlSEneujDIWJeJwORAPau7avF7qGaXbCjpq0oOye sUmBIo+zYpyYapu2qWlDX9Na0LCmHtCQydTTtZUdTGe3jq0C1mRYLlDvJq2n K9rcBkbnyyvXgIsdTNsobVNLSxvVCdDKbmaVp9LqbsZbtru/MKkNbe1tdEEw CMPb3Nl9eU9CSZk+ssrOzWBQ+9ZuaOtppeNAXwl2t4OiwvxBVF1btYTyGhw6 dyDGj0XrJhZHrdfGvmgPGwbsXnO0u8NYQbcxb4bc09rZt6EF9tCmtujmhLn6 0vIpHkgyChagZcLEja8RpsUMa3PvhIzpwpqMWa/76m7ZlMcJjH1vdATjNPXO pggrV1TAIZAzK1KSq5XMmDWtIFJQoCgrq6GyYMaMSASeJUUlWsnM4tLiUov6 L3bdv92MtJRvTI/tQwhXo4aTRF2dydcs57b0oj5sAdfgw3NwJmrXoXOvuTWj psq49JjcYtRxu7inuee5Z+B5YHL7OfVfvzb4+rXB168Nvn5t8PVrg69fG3z9 2uDr1wZfvzb4+rXB168Nvn5t8PVrg69fG3z92uD/w68Nxu8P2tC/ullItFwI eUJbO1lN3zm4X249n1mNnnOwxuqq0IdQvhydBvwPoe7cW4dz28Zoxvyrzq/s caJ1FYMm4yRqFrLSJnbfcW77uS01xunbx2K/TrYrJ2N/VftkTnX+Sx528kF+ Lj+Hn8/P5GfxOn8eX82XTsb+yvbar7zRmait+tJ6EjXVtIRnAM7ktonaasM3 vfwLM55Ujx3oj1wGaMmk9vG6/1Rv/kPe/Mf9/Tu9Mr6XR6PZ6E30FT8/RbXc PciG6X9eZojbO2B3FeqD3N0DtqRCvcLO3YFqIBEU4xajIUgEdXK3om2QCKBX 90+bUXiYAgOqtdAO+DciDdJ2SBzaD0/Myjokin/jQJKHdn9tv83B6L7RXxBJ AAN2X2FNhYvbgjAX5TpQBgpyV0E+BfJmyFMhX8u1gKWg89QHbPbC7TBeOaCX c24wQ0GugvOgQsgruQBKZmh9/dbEOH39OXmFFSo3n/MxFBtnAXsU5GRO6i8M ak9y9H+Zo3O7BhQTnd+ufru78GnuOk5CLsDaDljeoO1pTkX5kOhKagcUS+Ge CjNXC8usBbYEOfqx/j721LmOfugIxlvApSAPtF3OpSI35FXclH53cOhJ7jaG 9m3aC4w3t18uotmAxVo4VKFw9O8BYtzNwPGb2Wh7BkKzClFFiMtBBZAIMHUb QNvox+LcboB2g5h2g2h2g2h2wyx2IxEkfwO03AA4+dwVqIvbjPZA2gcwD126 +4GDhxmQmVN4mPNzPuCE/UngHYbawIBipTPz9TuTGJpvwGwtLH+a60FLIRGY fO+A11fY+SSXx5YydcCXTAm6+hUzsM6bkAUQeqgMnuZSuCmME6mMA7GKIJQx snFBhMkvyVHKHfIqeZ3Kl/7vLFn+KyN/2ch/nchHh8jRARhFHyS/pfnxihRC /5puDXkH7QOIkCfJz+CoCZK3ySCdBXmLHEblkB+DcgvkhyEvgvxIf9ovgoNk cAAymPu9/RYPXSz5WX843wCCWQbgTTYAp6ewIos8R55FKdDFm5BnQv4sGULp kD8DuQ/yIdKLfgH546QYzYH8oJE/T56iOk2eIIfgzAySgX4rnUKsX6LZY/0i zX7SjxKlmvzgU+Qn5FEUANQf94cCUPvwQCgzaHsS+sPkAdLbnxp0Vqjke7gO nwKk/egYzZGT3N9fQjvZ0/+UFjxM9pA9uq9Ez9Kn6Q9yBVkF0woe5LQsbZpW oj2oVdjJzUgA5sGGJTfCE85nAtoDSYe0h9zQz5fEKkZgTXRdBG2H534GNcKz i0EInvbx1pMMKifXoaWQCPRxFaRtkLZDuhrx8LwC0jcgfRPSlaymF1IfpM1g PrqAogsouoCii1F0AUUXUHQBRRej6GKj90GiFI1A0QgUjUDRyCgagaIRKBqB opFR0Pk2AkUjo6gBihqgqAGKGkZRAxQ1QFEDFDWMogYoaoCihlHoQKEDhQ4U OqPQgUIHCh0odEahA4UOFDqjKACKAqAoAIoCRlEAFAVAUQAUBYyiACgKgKKA UWhAoQGFBhQao9CAQgMKDSg0RqEBhQYUGqOwA4UdKOxAYWcUdqCwA4UdKOyM ws7k0weJUhwHiuNAcRwojjOK40BxHCiOA8VxRnEcKI4DxXGy+QB3tOLnQHIU SI4CyVFGchRIjgLJUSA5ykiOAslRIDlqLL2XMYOA2lwFaRuk7ZAo7RDQDgHt ENAOMdohpl59kChtDChiQBEDihijiAFFDChiQBFjFDGgiAFFjFHsB4r9QLEf KPYziv1AsR8o9gPFfkaxnyluHyRK8d9Xyv+2aMjVuE6Gw5Vsx7ks34Y+ZvlV 6BjLr0QHWP5N9CDLv4GuYfkVqITlm1GI5dAfy3tRUMb9wRJbhQdMwFJIayB1 QtoH6TFIz0CSGPQKpHchjZJiPZ23SUulfdJj0jOS8Jh0XCI2cam4T3xMfEYU HhOPi0SrSCYWZkfBtKBb2HMbPP8KCQ4ReJYzqJxEYNwI2Nli+I2QiO4Y1v6a h1/Jw8/k4cfy8C15uEIh52OeWTrw9AlMHNfp5tDc4DFIJaHsuWCZbj70sTfY H5oZHMRPJbJcPQz5x5AOQHoQ0jWQSiAVQpoGKQtSkNXlAX6dnm50+RSkbEhp kDQ6BPJ4wLtxOmT9MLHgBwd+bkH0P3DVn50DdE/2ZxdANtifvRSyJ/qz1wYr FHwIZVM3CD8OknsU8sf6gyeg+ceJ7Ef9wSche7g/GIGsoT97OmQX92e/HKyw 4JUoyFPSWiNfAeum+fL+4CpAW9YfzIUs3J8doth5MFAWtObiOnQC8iyDKjMx UkZ/cA5k6f3BUooto2wqeCyiaWx6AiSacwMwob8exnU81k3B4eBtwY+B/C/A WFCPt7RBHrJXsuh/yUANPjXtu4BcEeyvUCk+nA8HjDxG88eDD2bdELwX+sJZ h4J3B6cHb542KEP1t2DeN7Ah+oPXaIPkUT0puD1YEOyddiLYE7wg2BRcHmzI gvr+4CXBp+g0UT2uI48eCtZAh4tgFVn9wfOzBtkUq4Jbg3owO1iqPUX5i2Yl +i2Z9hTlACpMjD4V+JuXNUh1fGXJIHboedJJaY90sTRPmiNlSOnSFClVcslO 2S5bZbOsyrIsyrxMZCS76F9ph+mfV7pE+v+3QCJPnzyD7YQ+SeLvbwmWCboA xZK4alK9Yh6ujg01o+q1Wuz0ioxBrC5bHRMy5uGYsxpV186LzQpXD0qjy2Ml 4eqYVHNx3QGMb66H2hjZNYhRbd0gHqVV1yXT/wnrAYyu+1byYYSx/7pv1dcj n2dTua/cOddRWlX5FY9G4xme+PFNBlNjd1avqIs9klofK6TAaGp9dexq+r9o PUxsxLKg8jCx0qy+7jDfRWwLltN6vquyHtBOMDTQZiugoWyaAZo8D2kUDezJ PIoGMkrghYAc8NJoBniqBYUYXki1MDweU7wDx7QFlQc0jeFkIXSM4RzLQpNw QGOAtvJAKMSwMjRcR7FwXYbGJpbLOgoGAWVakKFA5BZkHQUxGyyWP4GSZaAU j6MUs7E4PIETTOC4csZwXDmAE/6//InOC+OBGX1X/Yz+X28bMxZEITX+77au 56VhGAqnnTjnL/Qiwymulnkw1DFBd3DYdrSnXQQ9tJ42ZaAnhTZ6m17Fy/6E ehk7pi2ICoKwP0zfS9uh2LTpS9+Xl68kr4R3yePPd1dl/nhRrYYDlqbD3ele XF6h7PU5U/sWH6hWNWxMcuAJwg3VCsnEPnPCidG3oobRsNWe5cZ6yzH/cD1N uZxWzmAtHMxBLt3MgU2EdeQykctELt3QBZd9jX5/4oRzpI0HwAkZywvz4MPd iuK211Zuj9Gh34+U8qDyMUOkMVmgLl9U23wJKkKaqZkIwX+G0DKmNk6h8uBI qXxI4xRaAfWq2p7mSSLYCbMsdrhyeu6gq3Cjl79mHhYBl4l9bcEN776ocP3u Sbzc4ucVxpiHD0YhSu7w3dMOP8Scj8UiUHUtF3R7ma5QELqwVLLfvr8ApPAR ko902KISZjgz5iHqKsrBbFCUMVTw4/XN/ZtP2MEfoEIcJ99HdREvy/fxdg3j Fz+uHyQS4lOU0bqyj4fRNMEUZS2RxqoGjWFtqA2bQS3QgiYm5HodgXJrhFtp VB8ViE+9bCKg6bskSbwGfC/RxqYgDrBBqUs9KTmt61+RskmfTqyXjuqJ4f1s QRK9R5LOCUhZZsRSEwEyYSIIfwAT84NVDQplbmRzdHJlYW0NCmVuZG9iag0K DQoxMSAwIG9iag0KMTkyNTINCmVuZG9iag0KDQoxMiAwIG9iag0KPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yDQogICAvRm9udE5hbWUgL0JBQUFBQStBcmlh bC1Cb2xkTVQNCiAgIC9GbGFncyA0DQogICAvRm9udEJCb3ggWyAtNjI3IC0z NzYgMjAwMCAxMDExIF0NCiAgIC9JdGFsaWNBbmdsZSAwDQogICAvQXNjZW50 IDkwNQ0KICAgL0Rlc2NlbnQgMjExDQogICAvQ2FwSGVpZ2h0IDEwMTANCiAg IC9TdGVtViA4MA0KICAgL0ZvbnRGaWxlMiAxMCAwIFINCj4+DQplbmRvYmoN Cg0KMTMgMCBvYmoNCjw8IC9MZW5ndGggNDE0DQogICAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+Pg0Kc3RyZWFtDQp4nF2Ty26CQBSG9yS8wyzbhYEZRqiJIfGa uOgltX0AhKMlqQMZceHbF/4fm6YbzTfnwvngTLTarXeu7lT05ptyL5061q7y cmmuvhR1kFPtwkAbVdVld0f8leeiDYOor9/fLp2cd+7YqPk8DJSK3vuES+dv 6mFRNQd5xOGrr8TX7qQePld7Hu2vbfstZ3GdisMgz1Ulx6Hnc9G+FGdREcon u6rPqLvbpC/8k/Jxa0UZHmjOVjaVXNqiFF+4k4TBPI5zNd9u8zAQV/2PWsOq w7H8KvyQrfvsOLY6H8AATAxIGEkBFpAZwBSQsiYlrAEZYQp4Yk0GmDGyBSwI S8CSwOesAFNOsGaEDTaMcIItI8kAOuZz0EDTJ5sB6DPFOJo+GWvokzJt9NkA 6GOZNvo8AUYfzKbpk1kAfSwb0Mey9ejDBvSx0Nb0SVcA+hg0MPRJ0dqM3wev 19DHYgJDnxQvxNAnwScx9MmgbeiTMI0+CeQMfSzTRh8MauiTWC7RfVmGfcIV +N3W8up9v6i4KVjQYTVrJ7+3qW1a1I0/P7BF0Y9lbmRzdHJlYW0NCmVuZG9i ag0KDQoxNCAwIG9iag0KPDwgL1R5cGUgL0ZvbnQNCiAgIC9TdWJ0eXBlIC9U cnVlVHlwZQ0KICAgL0Jhc2VGb250IC9CQUFBQUErQXJpYWwtQm9sZE1UDQog ICAvRmlyc3RDaGFyIDANCiAgIC9MYXN0Q2hhciA0Mg0KICAgL1dpZHRocyBb IDc1MCA3MjIgMjc3IDYxMCAzODkgNTU2IDg4OSA1NTYNCiAgICAgNzc3IDYx MCA1NTYgMzMzIDY2NiA2MTAgNzIyIDU1Ng0KICAgICA1NTYgNTU2IDcyMiA1 NTYgMjc3IDYxMCA3MjIgNjEwDQogICAgIDYxMCAzMzMgNzIyIDI3NyA2NjYg NzIyIDI3NyAyNzcNCiAgICAgNjEwIDgzMyA5NzUgNjEwIDU1NiA2MTAgNTU2 IDU1Ng0KICAgICA2NjYgNTU2IDU1NiBdDQogICAvRm9udERlc2NyaXB0b3Ig MTIgMCBSDQogICAvVG9Vbmljb2RlIDEzIDAgUg0KPj4NCmVuZG9iag0KDQox NSAwIG9iag0KPDwgL0xlbmd0aCAxNiAwIFINCiAgIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlDQogICAvTGVuZ3RoMSA0ODA0NA0KPj4NCnN0cmVhbQ0KeJzUvXlg VNX1OH7vffs2773ZlyyTTGYSMsEACctANE/ZBGRfg4wGWWQRJYAIihqqAiIq 2oprK6hVcCkBAga0H1O17gitW7VVaYtrRfm0lCqQmd+5d2YC2H5/v37//DF5 751333bf2c+55z6WLbl6DtJRK+KQM2vRzMVLL7ptCULoLYSwe9byZdF7/nTO RwAfQkjsNXfx5Yv0y1ZMQEi2YP/Ky69YOffZyivvQMjVitDSl+fNmTl7zOIa E6GfDIF79JsHDZszP5FgfxXsV8xbtGzFNeUX1sD+ZrjnyCuumjXzW/SSgdBN 38DxJxfNXLF4gfo2j9DN98F+9MqZi+Zc+Ot9K2C/A6Hk7xZftXTZJlSdRaht Az2+eMmcxfv2/Otx2H8aIRXaEYYf/acDKNJ9wvGCKMmKqumGy7Rst8fr8weC oXCkqLikNFpWHquIJyqrelQna3qeU9urd5+6+r79+g9IDRzUcO55jc75Fwwe MnTY8AtHjBx10egxY8eNnzAR/f/qn7APhWAJC0+gEJ9AQYSyX8DyJd1m5me/ pMfplnwNJ3fkF4S2omfwfPQMegG9iI/CVdvRXtSOXkMBNAQ9hFahn6G1SETT oeVWNAF+ArT/DIey7agWbQFe2oL2w7lT0Q1oH/LjYPYrdCO6hXsHrroFGagc nY/GoavQ7fii7NVoBvqUvwn1RxehK9Fi3Jqdlr0je3f2MfRLtJd7LduFNBRG s+C3P/ut8Ifsn1BPuOIedD/6FN+t7EYOPKUVzvw5WoIe4NI8zl6ePQE9KEPX QB94NBrtx50kCXefg77AQbyKGwx3eTTbln0ZzipCaTQPPYD24b54OCkTZmRH Z/cjPzxjBdz1frQT7YFfB/o1+gjrwtHsY9mjKIRq0Ah4n3b0Nu7kMl2rM40U 0YClHigFR65C/4NeRQdxDP+GXCXoQh/BEa7Nvou8qDeaDL19Aq78HP+L3AC/ G7lX+GHZC5AL8HIXxTb6LfozDuNaPBZPIT3IVeQX3BIkwxN7w282mg/4vg/u /glO4j1EJwe4R/mn+JNiceZQ1gUUSaAH0c/Rb7ABbxrFS/FP8Pv4r2QwuZQ8 SP7C/Yzfxv9emglvfQlahG5HT6F/YTcegMfji/E8vAqvxXfh+/F+fBB/Sc4n k8hC8h03j2vhfs1fAL+J/FL+JmGNcJv4ZWZa5uXM7zL/yvbJrkHjgR9WQ+/v Qb+AN9uLDqAP4fcp+gsWsIZd8IviMjwZXwe/G/Dt+BG8FW/D7fCUg/gv+Cv8 d/xPfJIg+IkkQspIOfxiZAm5hvyMPEQOwO8g+Yb8wAW4ci7J9eUauCbuKujV Wm4j/HZzf+bD/AE+C3juI2wSHha2Ck8JLwpHRV36iYzkt0492lXd9UkGZdZl NmV2Ztqzf0Y+oGEYsFCKGqD3M+G3AOi9CThuO3oH64C7MK7G5+GLADOX4gW4 Ba8ATN6MH8C/ZH3/FX4esPQB/g76bJAi1udzSF9yARkLv0vIHNJCNpK7STt5 n5zgJE7jTM7HVXPDuTQ3h1vGreQ2cW3cW9zH3F+449wp+GV5lS/ly/kEn+SH 85fyV/O/4L/gvxBmCG8Kn4mquEhcI3aI/yv1k86TxknjpbR0p7RHelduBu58 Ce1Gz54p8/gQt5obyu1Gd5A6PkTeJm8DP1+KZnOjCXAq2YrXketxO6kQVoiD yCA8Bh3lE4DrV8jD5DgZxI3Go/BEtID0zt1N9PJPwqaBfwkd4Z+Hd3sb7rxC 1PEN5DtRRzsxIil45m+5XnySexN9xH2KJX4L+iOv4gA+Qp7gxgEX/Jo/T5iG yriH0K+4Fnw92k2GgsY+KW8APh6DnwS9MAn3wd9zWcSRMcBF/bm/opvQQvIH dATkeB26F8/mL0d3oDq8Cn2BHgep6CFcKVaLPvw6mc+vJx7cjgi/Dd4uhSsw J3jRzTjNPSB+Rz5EV6MDvIo+4Z6G3h8gv+JG80eFCXgeSMD1aA1qya5GK4Vp /O/x5YjDU1CcPwTabRXXhy+D7Y2gVWaATtsD0r0P9MD53GhoCQLnXAR8MRk0 xAPwuw/0BA8cNB9kfCposbdRuziJdKDLBRcGrYMQ/2ZmApqefRzdn70cXZm9 G/UEfbA2uwruuBV9hu5EW/EtmevQYlQCkvMJvkgYRg4Iw7I9yXryIZlINp1N X8B2HAfR1/D7FeycJzyH1vMfoImoMbsh+x5wdxVo2PvRZWgkOgxv+S084UKu E9VlxpAd2WHcYnjfT9H47BPZUqyiedkr0Fj0PPqlJKCZUtIZPHnS+U7jeec2 DBqYGtC/b31dn969as/pWZOs7lFVmYhXxMrLoqUlxUWRcCgY8Pu8HrdtmS5D 11RFlkSB5whGNUNjw5qjbYnmNj4Ru/DCnnQ/NhMaZp7R0NwWhaZhZ5/TFm1m p0XPPtOBM+f+6Ewnd6bTfSa2og2ooWdNdGgs2rZ/SCzagaePnwbw7UNiTdG2 IwwezeCNDDYALiuDC6JDg/OGRNtwc3Ro27Dl89YPbR4Ct9uhqYNjg+eoPWvQ DlUDUAOoLRBbvAMHzsMMIIGhA3cQJBvQqbZwbMjQtlBsCO1BGxcfOnN227jx 04YOiZSVNfWsacODZ8Uua0OxC9rMJDsFDWaPaRMHt0nsMdH59G3QbdEdNZ3r N3RY6LLmpD47NnvmjGlt3Mwm+gw7Cc8d0ha49nDw9C7c3D142tozj0a49UOD 86N0d/36tdG2zeOnnXm0jK6bmuAecC2JD2tePwwevQGQOGpiFJ5Gbmma1oZv gUdG6ZvQt8q935zYUNrSvCDapsQuiM1bv6AZSBNe34YmrCzbGQ47e7OHUHho dP2kabGytsZIrGnmkKIdXrR+wspdIScaOvtIz5odlp1D7A6XmQd040xgTvcx BrHTKTRqQjdmMe1RbAQwRFt0VhR6Mi0G7zSAruYMQOtnDYDT4F8ThqvaZgNF 5rcpg5vXWwNpO72+TYhbsej6fyLggNiRb85umZlvEePWPxEFKZ90sxocL8Bt yWRbdTVlEWkw0BT6eB7b79uzZnkHicUWW1HYAPrQOMDtzKaBtYD+sjJK4Ns6 HHQZ7LS1jp+W24+iyyI7kVObbGojzfRIZ+GIbzI90lo40n15cww4uZ25v742 OdH9Z1p+z9B5A9uw///l8Jzc8VETY6PGT58WHbq+OY/bUZPO2ssdH9B9LA+1 eQZP4yIkD5EIx44CU87oPpnuTNPb+Dj8iYypZ3dIMnAla8HRYW1W84W5dZNa VvZfXtSRPUqvYpvTl+W72TYwefb+oLP2z+qevp6DDoMZHDVp+vr16lnHgNVy DxyR3wDHo0nTyqKD29BkkMw4/HVkOwfQpSnS5gDKBtMTgP9yTfnds06M5OEm +Ee5s2fNMFB069cPi0WHrW9eP7Mj23pZLGrF1u8lL5IX1y8e2lxgnI7svtsi bcM2NAGu5uGBIBQEXbAjhteN3+HgdROnT9sLwVl03aRpOwkmg5svaNpRAcem 7Y0i5LBWQltpI92J0h00CsNL7iQyOz+y10GolR3lWQPbn9WBEWuTC20Yzeog uTar0Eagjc+1OayN/qM6ZvCkaWdyDxPJpp7AjQQz51lA4I1DpFhml9lxWGEw qKeiXOcpR0AnUZTvpLHd3OwXwnLhHVSM3tk9iywoJrgj+2W7pomTEQDOpRSK oj7GLLCky4pb0c3FG9EDwlPcL429XLvxqnEQHS7+R7HtchfbxcVctVhlVxdF S4cbU7xTfVNC84SFxde5b3M/wN3veqBoK36MbLXfc3nApoctrxXmSUf2k51V KXhmp9OzKmWZCPMRT4nORUp4xUqYI1EiijEOlwYSURnLOu2NHCqZNSOYHGMd S6ZHHxljHYf1sSOo8UjjETuQ6t0LJ5PpdAtKJ5N4CQ6IfKy8gvStd1fU9eED UiIRKxeJz+v21/Xpx7e/eG7mpc+OZD54cDse/OKfcM2gF+pe/Om2v85Y9Pma R/9CSO/vTv4GX/n7z/DkHYfe7Ln57kcy3931XOar9c9TzK0F9NJYz4tn7kX+ bOcuX6Ce68geclyGIU6O833BX9xn8KxpYCBUH5Bt3fZyAkZmkSB5NVWPK05d v/qsgjsV7Hc0jUz2O5ZFJitVbO11uWDdkf3GsQ0DIF7XYR2m50HrcbgAsKF4 LUuk+987Gn2uopom2z++R9cBGOOnuA3U96tv8x/1k8X+zf42f9bP+4k3jhE9 ZkEfjlItFkUH0SHgkY7siXbaAQo4AdoJxB6NZPpoxOeZ44Tjp49ChD4HnHZ4 OBrjGz4umLSOJ/P/0i3Jhq4GCzbHkmf8g30gWAOQzE7ZKewGqg1e6bhElxR3 iXoEG7IZwSgJlFyNkmnY1tl1dr+6Pn6/z47Z9ZSGos9e235D5/JfjWq/euG4 2xuEfV1/vzv92ENdl5Ita6+beMf1Xc+B5IzKfsmX8OeB/1aMJzqBUlTkI5O5 tJBWJmtzuIXCVcocTfZ1ZA+30+7bADgTKFRcRNeV7g+FE97jYb63e2Cod9H5 7tHh84vGu2eEJhTNdC8KzyxaIa7wHSfHgxYE5KYRCIzzN/sX+zl/kbnR2mwR y+IjRaqE9pEnEc52MqQyVrcozSxg7Hs8RbwWcIyO7J/aKY0B+JZ1BYCv2yli DXq+Ulld32ZgI1wKe7viiXq6dc4vidX3KsWl/jqrQnIqqutLpUZprMRJUUon KUhpJhXR20ouSjOpiN5Q8tP7S6GS+v45IcpRJDm66/AYqyWZPN5C90dTgeoC GTrceMSdqk03dLU0YNudSlFa4TSVriRuofIlxsqRbaG6Psj2SmV+Kle4LFFJ acRdsq/m271fZb7D3j+9BzHrqS/VnbfM2tD1ERmvD5hy66pteErg0XZcijkI EKsyn2R+sKLb983D96wZPO9x4Mhx2S+5I0C9MJ6+g1B159S7bjSxqWEHjQN9 xCHeXaRJQcAhdvkkmbKqpLMX1tnLWwwRtfSF9r/7ClMR1svpPnTp3SviDFd0 XFo02DM4MNEzMdDsaQ48SB7kHjAesx4L67IRUheQ+dwC4Wp9sdFqPK7vVvao u3Xdr6/R/0o4V/ml5lXmjSZn4g7ypLOyF6KdaoZubUSbQY6OIgWZpoZO97EI ul7hkin6XeUReL8KLVmKMQI+cCh9sEPZAl9IqYTD9DQ8oshXcUDClLAkT0SV niS5GSl7R+pfzotbuuVITuzSS/JGYS/luQFNR5YcSx5Zwt4dCGmnaq30Yfjr 3QulW3C6palAwno3FbC8hvR5KR25hh3F3/3qo8y/lnx16zN/Kt0eunH6uicf u3nBHfiWwLMHcDFWn8Zk9fYtkYVXvPTO+y/+hGrFdaAVvwetqJGZTkTUGa+J U8TpCmca/xCOi5yiUzEQO7LH2imN1AKgFACO2h2LXjiZu0YlbjHqKauXwR/Z 5a6sh7OOtsPWLbCGMtbg3AwtIs8LvNhfGc4LcbGnOk29hrta/Yj7qyg9LuKY mJDickocoDQaY40mvkmcJjUp1/MrhfuVV8Tf8++Lh8WvpH+JP8g+t6oKHMcT UZQURYYdRZbjkuiVJJHj+bigegVBVRXYkTFBLBMKehGpfAc2HUXgKWGEcpnu lUUZ3SxGq/BGEGAtjkgc440IN0KESECLZpzeTMNalG2RxfSsyvSsm+lZRmjE mAaFdOPPZcPnBpPJMce6NWnDaOuIBWaw5Tg1h8eYYrXgB+q1AezhWuGcJH+9 9TJsg0kXAJIlN8gNHFvvEJlUGaMUXKrczBElaNj1oHFbmkDIwU90VKWmOKXI xcUNIrXUxSnYvLszyjY7ylKsC01p1JLGLSiZhCv2IjHbubMsBUTs3Omnm092 Wikxt2F7Otvs0HIXJ5tAydMLHffHPJa9fnia19vAVnDV8Z1BevE3OyK503G6 iakeCrUwq4DrMI5hyV7Xjp/8KrMAv/BJZsuNwr5Tz+O2zPKu2aT02szF4BGh tZn5fBnoEjcqwZc5d+hWT+tca5TFN0bboqQ02kOPFffx9Sm+oHhxdGNUHhgY GBkZGBlpki/WZwRmRBbIC/X51qLAwkhn9B3vx8GPw++UHPYeLjkUzUb9MT5p JX19+YHWMH6kNd36TPtbccbSbBcYgiJRwqK/yKUhV6jioIot1VGb1VaVjzJ7 H3Uo2UEGPnc00wQomN8/URCOb5kvxqSEWluVCkeM8oS6DHvqSJ07jlAncBTe jNvwUcyX4kY8FhRqR/aUU0w5CzPOwoyzMFOImLlRcMbxdqZw6KnMlGOdqR43 Uz2h0uH9g/i0hWDMtgS4revYYavrdBPwG+gW8L2YaUBpIMwS1OKx63z9chbb S0C/JCptjumUvsx6r31s4N3z1h1ccPWn102/8xz78eUrnnpi2dIdmfnCr9eP H78he9+jmZO3XTSw6yT32P6X33zvzTc+oDQcAta8EmhooBBeuMcXpP30UHeV AibFzFIKhdgBt6SG9OHihfIUsUm+XJwvy/XWQPdAf9/gUGuUe5R/aHCGMEOZ YKXdaf+E4CJhkTLbWuRe5J8dvAb7FFEwLuYmCZPUi/UruDnCHPUKXQ0U8ZJd pGneiggjW4SRUAJL7diUeBIjXt7oUD3F9DUFmBakAMUyA5hKoEbcUxGv7yVh JFlSFEx3708jOELbR1DjDrCrAukuk6oDpiCYXUNFTEEwe4CYt4l0SknkZ8rC gVuWokZAWO8wNfLgIXeT8AiY+PTx9OmGZM5zBnlvATmmgqhMFCYqlwmXKTyV NnqKx+oPpEQ+L7MUnjPoOOSxW3/7R+y/7m+3fZo5snfn2jU7d92ydifx4Mo7 lmf+3LX/bz/BJdh46823fvfbN9+ADoF1wOCqsbhkv3OJ0o++yFhlo7JZaVM6 lU+Vo4qElFJlsdKqPJxvOqRkFbVUATsp8YQDxXsDRqIg8qooxQXEP8xv5tv4 Tv4QL3byR3lQyVH+IOzxPPjEzOXiu/1YnvmxPNOvvJeij6d+FsUdABlGJ56K g0oRyY+Rf+zNLgFvFvgdPFfmDNGFukNLWpKevnU+DvTRuvb2dv5vBw6c9PGJ kx8V4oTPgWv9+HrHI3Cih2y1Oqy/cl94jnLHPSJPDViDZtSvtPB91sHgoWA2 yEdlr8vrd0OcANrDUA2X7qoIstggyJhOYxGCxiIErTtC0NjraeXsDNAYuQhB YxEC7P+QixA0FiFoNIJgxkVjQYiG4U8bE6S8F6bRQvBokCwObg62BTuDfJAj dT4/CxiOt9t2Ljb4z0GC+qMgwT4jSOAZr9JHuH8cdIwJAJu2nGZLQPQxFjic 1Ur5FWwbjR2oxilEDn7RVlRZlVROtBK26IpgU3XnI4jq1aCRqE2royqJaqRA Popgjo699pGrP27eMs5S26sXXrj0CT5x7/ahi0f3ub5rKVlz5aLz736ri0V7 Fdm/k2rhfhRAf9iLVPDCYwnqe4AXDkBrCLhTN1TMIb+lJE0VVD6nmVY5KseG O67jrCQPVYY2S4ulVmmjxCOQ9c1Sm9QpHZREiSp5ikopp+QZ8Pd25sxSFmZK hQLMpc3hPadFqM2g7lVemeT0oLSPLEBB3G/H3DNZF94f1PYRGowdPtZARR5A qrLtujrrdcrDyWQ8QBV1oq8d61tn9wdsxWwv9eeJFb6o4bIram6+edfu3Z5k VcmWh63z5jxCZm3A0hWZ2zd0/XR0TZjq5wsy47mvgdNLUDW+ymnWNMFbo8W9 F2lDvaJSHCqu0RLemlhK6+cdqQ3zTpGmafO0E+o/fa5zYjWV58XOq7yocmPN 5hqpX1m/Ho01w7RhZUN7TCqb1GO+NKtsVo/mmtaajyq/LPs29l2lHfCLvg6y o72qyCMx/9uKol7M+25FncBSEuog1zt9hKIiUx1aXqSrfl9dvE6NB4MHA9gK OIHmQGuAr3E0wGkN0+YBN6VBgIoN0+YBkVIg4GfHqI5nwkTPEun+t0yFB6iy GEnRHlhm4jgqL614wTxgfmpmTb7UbDTHQnjAojEzTKlnltO7mUX0TibzjWk7 rEPJmmVl9ePO8OzSLTSrcdrQMlfP6jp8nBLvMI3NDtNtAyVdC7jygQDwNejl /v0qgYo04QG8HgBCMqWdOFNpz92u9Rm87Pp1QRde3vbHo1f+7vbnr318zh83 /8/X9z9+/aqtz1y7Yuu08Ph4n9nT+7fdhhs+vg/jDfe1nlrw/YEVT3HVv+t8 4a2XXnmJykQjxGc7gN69uIBzHV/uLR+ojFSGVEwpn1O+SrlDubnicc9TNS9y hhIIBwO9RtW8HxAiZDIhVh+sBmfIM5QZ6gxthj7DWCAvUBaoC7QF+gKjPdFe aVYmKiorevSrmK42abMTs6uWxZZVtFb8VH1Iv7vq3pp7ej2mbtMfrXysalfi twl/FZUbiszyAhArABUFoCoXXeTPoUCsAFQUgGLwSx13SWq6XBnXVT4cTfh4 7ZziMGWv8lANJWNpqDE0NnRpaHvoQEg0Q6Whq0KfhvjS0J0hEvo1qD0fiAGL 9R0vPd3CDiYWPgiBArYwTa117vL663M5AJddj/E5M4qvKCbFRT6Jp91ghgm8 wYJJ+tzxUBHni87RSsM4XBFyPMH6PvTyWsqjoWBuTbkq5KccForSK0NRelWI BR4hFu+HOsjFO6WKarh0d1HqYDWupk+hV1RTxUFvwwB6BQBf76EXVYfZo8oq q+ub+3T2IY19WvuQPjRvUYGCuXiFKfRoDsvgzlKAdoACToh2IlphMofIZN0z o0wAqF2I0meaLsb+OVEo/7QQFoV655MTIAV5eTgCiwWbJWOYUaBNLUka73Tb BRrjwrbxSAvEucxYJ8FRZRuw0/AHJjuQsxdOZc+SGCinhG25LY/FieVGNIKU KimChZ6wKvHCbpkrFkHlMUOXe6gRXFWpqGKSj6BSq5haliSNsXIrGsEkq5Or V69GZwgr9QrSnv7+nNxVJirPAaEE8cyZoEKYTaU2UEJyrlWicad563WrVvSN //SV+8eeP6D6ronX/3q63aYvnb9qgd9fG7n5hXunzH/l+gMf4nOLFi6ZM+Tc WDDeZ8TqMcNXVpUmL7zu8uCEGRP6x4qKPWpF3fmrZkx/eOrTVC+PBL+5COS0 CvUnPZ0axVCqQ0a4uodRXZ0y+vn6RwZWj6hOG+nqBcb86uZe6401PR7wPxje ZviqCsngSupdhyj0eOjJqj2h56peDh2o+r3v4yp5iB+XMK1JSelmLoXAAom+ NPM5mUKlgdJgsqa6PsWnakbwF9ZMkZuSc+X5yeX6Wv11/Qfjh6Tdv96Feau2 oj7Qp8wbvLTHVT1Ij6JaV6PrTtfDrqxLeNi13fWdi3PplG1cOa+NAcccH+U4 F+Mhl0h5zuUq4gIgtXuC93iLisAUwElMz6KhlWofsMw9Zlozkcg4OF4G8v8N uxkFqIsEEHNlKmhekPJuRU40mar4k6PRx1WwB8H+qbwOIRc7rkoHJaxENNEr sT0hpEB0mBFPdGTf38OA3rTNMahnn+pMkc0pnGL25nxmU+LB8tqKF8QDIikV G0UiuuibiiydJbJcnqjTzogsehOZ2y8yCRd7D+g29BCPHTuSzItI+rR4NHQl P/uMmv3DICBdVCBqC+e35KSjIB65+BqigWQStcQZWwLfAuPSH2Vk4Fup8jyS 96R8Xn8gluBEyUVySSM4iWuYvXfB9ueHL72w78KPLsd1Q9fduLK4LXjlwVvX PTnOUgLlzxcFLnv5qhl9Fs2f90ii+KbJw566ZczqMV6XEa6Iq1f2PLepJdhy 2yhn5shzVhw9ecu5A/DHVUVW1ejaC5svHnvuNTmfWkwAR8fwq3uRkdfxckHZ g1/2B2c0uNRx/jB/WPlz4LOo8J5wPEoCcjSmBCNRheNiJUWijxpi8LBj4ZCl HozjjfHNcRIPBMKu+EYb2zxlCpupWJuxBiWi7aWksKk4BCg5bELJYbP4y2ZM YeeidwZ8n88r47SjB+MbIZ5jt4t03y7Cbgf73zo2vV2EOc4RluSL0OwQc9kj Or1xpMBtEXo/PyJ1sTg+iDDNNxIa8I2FuIpeU/xvGSXGOcifd8pPMR3NxMLL vHMW7uQjyVBFvAOv2FU2/ExvpBD8dx0+Mx1whvZNprvGDJ0z5HOI/RsbGsA7 z6Wl7ABlq1Qhwa97PQmvbkew2/AVEvz5ZHJdIWEQoKszHfQzEv5b+jy+YPm9 pTe88Ysnd8VmnLf4Z+3TZl+0eiCfuGfMpZdN27d9T1cl+fkVlw6857Gue8nO FSvGPXBX14fUUwnTsRo+gVT8dT6THBBkpMoiFlUkKLKAiVBBKSPUJj/eb328 H9xiiPMaaccjz/YVMCq3Uyr1Dww7pUBgVi/TFQE9tAu2OL9VKeMpJWX1qApW LFejlMfrkR9WsPeRc0PVOfUoCitT74GqlISaQn3VC9FwdQqeQprkacpcPJfM l+crK9A1+BqyUl6hXKOuxWvJGu5WaZ28Xvk5uk+5S30aPaL+Gj0r7VBfR79V P0Lvqd+gv6on0TG1Bl5HDSK/WoUSan91LHJURXDc/noBOKk+n+9T4H3oqyOa VnJMSnYVMf1JcUHbWAqIYoW1EkHQNaoyPk4CbmDZn9yfRLWNjTbDj9NflWQ5 rqheRVERRwjEiV6MoSMqUhVZJgSLkqpwCAu1OtbLZcdxIL4nSgeO7HaEVoEI ADlKlDi4XPv69zRuORIOdaW70uHgkcPp3LBDqjuvabOk5trrX157TpBumkBp 5TXW6X8o3VSG6zzATv09dRj/KnPF/xyOgxX6Zm/mSj7RdfPlV01aTtblIvQy iFu+Be4I43/luaNY9ZqcxhWFTLeoiR7HDV68o0dNJr1mqDYZ/jgc3A9qg24o oxxhujOyyyzCJmWTRUWpKu8Uc7vKOYZjEjNa1aveoitJV9x+I+iu1Cr1SqOf 3s/o67rf1qrcVZ4L/U3uJk+Tb757vme+b6W43FhpX+u91neLsd7e4N7gudV7 n7pVe956zt7n/Vr9wvtPo8v6wZstKnHn6er3aEUR3hxi3gxhR6i7+6x/gMQ0 y1kAuUxTt2y3G2gV8no8cbfqhR1TN209rqnguKoeasY1kd4AFVlFpLbohSJS 1EEad5uAC8fbQSY5WqPbcZNL3S+4ibsDX7DHxOVoaESlhxi2nKjeSx+rc+P0 rE50OGNXrQm4IY3tkegqiE0BeV0t4OABiQE8ErSOHQ5Zh8EehYPWEQahIA1T Kc0pveUzk9gI3mSty2pokF8e1eaaOKotOH76tOeQnv0Sadkv8YABTfkM9l7k zX6yp39KLe+fAmfhy92+lF3uY8nkJppYQMA1ON3kqcyZLvidZhpRotbvRu+g moYLA3ZC0DKLXvw4WV6a/Gt75orzK3qtmlKfuXybVVURWWgW81Vd91+9etVy svDka9svaJpI+coDzler8A4KYMMp8SoYGCfUK+SEFoce1B8ythly2Kgy2kKd IT5EHYOqcGl9sWxwulmkYh9Jej08BzL6sBd7sx6HD8R5EK67MRu13dV7QD1L pCSLSus3IhxyWCTgGFTze1lipoq2oHJmC2qYLejI/h0CXmoPvHlL8HXBEnzO UpM0YfMsswWPBkPP432oDB3HKgJDcPwM0QI5a7COAVlAwR9J03RYQ0NXQ+OR lJ1T817LFhVJlMGHsRR3BIFZjGDQ9dWrV+NkSxotqaMZhr71zBcGT5hqeR/N Nux8+GFP+KblF82IDOgzYciBA9wDG1oW1g+b6v65Oqz5sg2n5gJObwGcvgKW 30avO4NqPdjicYyv5wfzE/m5/DJeVGxZkRXDYysG4mSssQQ8qKGqjTKWy6Me 7CHl9v955Pv7QlLre8c+I6klMvt5luXMDX6LZwzPjHEPf/nfBr8PW+ljSw7n RDAFGGL2MIWs19e6rn+ZeltLcLpg+3K4kMDS3fLIefMbL77kvAsuGHSJt4RP bGm5cOATlcMbm5d0vUs56yZY9Wd51L/uEVgSVaBM0X9APdvW981te/XObcH8 0K0T9wXqTaFUeFj4VODHwuqowJUKi0EFZwUe8KASLocaeieGIh/Q6WGEO9FR iCP+E55O5L2NM5N/Oe6S86jKpVUByDLnBXXnV9EY/uz8KovZkrkUK8trLMk1 03Gem9qFfSeG0Xd/MvMJvgntRyoas1vlkPSU2IHHOQnMNYChUXEDfQvYQeIA aeBYdCm6Ct0IDpKANmtb7oOnHUuzRBhNItI1eCldLJnbu1dd3zqIw6RKcHb3 7B83tU+qH7d/f8ttidGhmRfD26+BKKoUcG6hYtzqPIgF3awQ+gpDBaGxtK2U lJaWF9UVXVC0uHRjqTjQ0+BvCF/kvyicltPGNDPtvyS8QL7CmGde6b8y3Fn6 of5R4KPQXzzfBL4J/bX4UGm2NBQVas1aby+h0XSEi8xxwlzho+J/8ics3fK5 eJGgCOVk1Vfk0oIVBzVsaY7WrLVqfCnLXmksLtJYVE5Tuyy01wqDEFph+AiA Q4wKLD1cy9LBy7BdlydfLj9bx8UJ+c9jSplCDUNhcEk/Y3DJfdbg0vc/HlwK ssElb25wqWT4mdUH3f6l1QUtPx5eoqNLtFDkzPGlsliuIgRCZwvFyis5b+B0 ggv3fKJ9yY7Ltrc4mb//+vmFpH7yXcuf/uXVy58W9nX9886xd76xNPNd5v2f 400vTL5t/5sHX9lPJSr7JXeIzubAY/eiMK25AFkhUY+/3qSZ1jq3tz7pwRWy x69jjx+MqmpDIInq/PFggCbQwyw7H2B5+YCbpQ67w8kAw26gOyMf8OaTiPma nQBz7wM0I29QJGUDuDOAA2PCTAJpMj58NEwWhzeH28LZMB/W40q3+lIwUqLK QeWQwisFsVS61Ve+ZkhllUL0/owUCsvGK6xkRxkTOksIaWnOv6fdQY8xOjTk 9BdT82HechmmQURJFmVB5kSL1yPIkO0Iop59dfVqIBZcW9aXpZUrE32BZEAm Sqd+FOYaV713yaNjLa1ds68cP/6OQe0PtV+4aGzfpeTurl239x4+fuKd60gK XDSChgF1PgXZs0H2JjuPqYQ34ka9McQQ+nr7Fk0lk9QJ3olFl5PZwhxllre5 qLP0XeE9z8ehzzyfeb8L/C30GZMxf2lpMkwFc1SYSql0DqkwzvEPJH2NUWSo Mcw7omiqOsW43PhM/MJ/Ah9zWdjHuTTLBNnTJBuB8HFasA6juG3GLeugjS3b sZvtVhuEkGUHmSjaLJFsdyeSbZZItplo2swEs4jRxSLGQiKZxorOBSxYXOau eEE6IH0qZSW+UNFTckZFT0muwIUNLubqK1hug1b0jDuzoqdl9JEfZY9B1TUw OtLKq4bTEkVH/vJU6psvA6Ej62ekjLkBc16+8b2rF7x7U/Om2l1d0aevXv7L rdet2LLmFxtOPvow5taPP5+4Tgwj7rfe+M0rH731MtXT+2C1FvQ0h+JOkFC1 3JBTxtsRvxmOb+aZPj6eTlMZz6nfffv376fX9kKI3wf0ltCtjiGQEp4jiJXC Kx1k6a4oj/kOjJ8Vo5jUgq4HeDfGUYRZyaLGLJPMvB86kMI0W0f2L+15H+hU wQwVDBPcUd5z/2kZSIN3k6a59vTnFrMTdKykd68yu6xvma/MJp5MMb8+ExGM Z5458Q/aWxEh4VnQHW6+OBc/7EVuSn1GqFyaScyP67/brhssxQv9pJAd1XMH OttduaHKTqeWQrbD9lWbw0gHnwCLJkRThi7S19FtTHiVt9V8LiI3SGTXJpP7 91vv77feTbKghAZoLKWTey8qjBHQAF5czfdQyUj7YvsOm7OjLP6jhiE//Hmo UAx31FFKy+qtouJc3Y3zbGlFPS/qikeMKCG3wCNe1BTNJbst5OG8UpEc0Ypd FSguVctJVz3qKw2UB7mGcMNFRxotj9IGm8Ptke6LzQnuhdJs+XL3SvFaaZm8 V9xn7nH/UzypVGl2FaoyKl1VZqW71jsA9XdfI6+R7+Pu1Z/AW8lW7XF9N9oj 7nO9xr8vfqh8yX9pfuE+Jp5QijSR9lhna0vMJQJZSpmtC+FRRHWZvBvZsiTH JTPuoqUTLokzsB43OrLvO/2pSBkQvVYzE2Zgr0dUNTuhJu1J/AR1hn2Fvcpe b6u2ykMsS8mRI8xpVOcirNrkMfij+9Zh+svl1+Av4ng5QQCFKQmKqsrgiquW bYN9GbVLQO5oR3aEM1c1XdGXbEmOShChJQXJKwiSC+gcN1xgOl0yqJSkKnvh ciR0R9qIYMnNyxDAuQzWPTfYEVmWJBp6u03T5UKq97hl4GaDlrJxRgd+wlGj Y1V8lXqjSiBom+woY218lX2jTWy6p1kCbmaeIQfB+RO78XHP8blMu4RGH0un g13pFvijQXo6+Hl3ZG7lf+5c2odG7TZbrx19ZsB+9ga4EkK5lyUI5+hCYbqM aiudOK3diOpR8nz2EMKwuLIH21EvM+oGHoUYL/evaVRb/USQODl7cIfUC7OG MogI61gJnJw9tEOK5lrd0FrCWuFGe8wovbfckT24U+pF77gTDSD7ck/qvnn3 dQF2nZ09tEuN8lE04MwI05V9d487hWpgoWVRHhpdNp32Z5NU/FrAb2EJCRZa egI0voxxlRwelXlu37ZGvm7b3of7nrtne6b9uW09PuATXQ8ett8gV3bd9+Z+ MvfkR2TV7lMHQNO8AOpmNfP739qNQSUS5t4PODfn5tfV57Y9e+W2VT1y21jO /d9VXJLbBsO5cKDasOqjwkZhu8BxUeCiO8FPbkN8Latk/BRcfsEdhcaNiGOn M18GBfOO/zfteQ37bUGxHndyycYoc/8f4d9vOkOnAqZ2tiIMWKBFFN2pmpyr Tx38F15kDj5GJkLc/4I2tfCf8tkYn4k1kScKBJQGSF0+C1ObZILHar4jz5pu bJaHWKWZMy6Umm5u4jfJ97seMDuFTrFTetNUTMefCnMexWeErb54oLYa36HJ te6pfJPUpE1z3YvvU+/TniUd+mvaG663rI+495TfGX+0PlPdBQWi6chtm0ED DLdINbiLQqaIiIFUlYiIldwBt4OqzWVa5ooiJ8mKgkVREXiO00wTfCYDm6Zh aeC4EUPjdEsVTWKq1ivoFYVYcaR4EVI4YrxiYCOuc15d51RF4TiIpg0Qa6SO dWP3COMGvVw1Z4rKDY7agSPPOuI4sVXkxA4y2HFFuRtI+VjA5Qh7FQtJ08dy CbVw8Ij1mXXsyOfps2SW5lfSeYlM59MrKdNcKzNJzK1hI7GMS0Oe8dtdweKU RvGtFaf08kCKg4Xu7yxLWZRfVF8Kl5elFKcoVSB3EyvFYHV8dRjXBWimpT+t 4OMqsYlvztz/50fPKaqJ7/ogcxe+7eOPBma+IlU488PwXhfUnczoXW/jkU2Z NLzX+biDLCCLQA5qnNBispgjo/FoUHYxRMLCYjghxC++naqrw2nrc1Q7GtwL 1ILTHjDg55MeuGP3bmq3t2S/EMppBT/60FET5jR+mvy6zLOCeb/HV1/PD5KH 8SPl5ebjwpempCOqGp9rFxVvghT4nzCHjgoAYcxP6JgXG98n6agfR/3j/ITW hLf6Ob+RiKpYZZiBu6tRKkgqjdVY5R8FCsV/uSyNyudL//7FPBaVuogqM9Zp 36Cms8Kn9JHRVjrdwoSNlW7nCgOS4NyBz01ycyCo+828b5tvfnF25uS7b2dO LH5x+DPXv79H2Hdqx8eZU4/egY2vuLGndr6w+7IXsZfiKISQtBxwFMR/dBI9 UMLu4U4EU6ifnXL3C45Aw+0R7uHBaWiqPc09NWjdJ99nkry01Fk4HEr66oV6 fYgwRB/lmyRM0i/2zRZm6wt9y4Rl+nU+U/DpYErdMrhrRCag0X5kSiNOCccz kynLggpYUQyXaepej9tNPzkQ9HVkG8B2BqN0q7ttunWm+2QlSq1jNGcdg4Is l/iCXp8v6NYVpcTnBtBtQ9AVtWwIxWy3ostBn2DaFtAYuiRwQcs0lVzqmgTd bttGcjgQCFvnK3g8iiId1j5YHCTg8XuidIpKKNSBb9uxNTdqHQ6NBlHr6gKZ C7Jhkf9oIfMFZHbOSv4XJpLKYcPLBejMFR7VZoKVssFK7XSrQeAlMFDQGIfG ama6EK0FR6PaNGhxQcsu3RGcvBVbki6kymHjziU/YzhRKUoY/yJz3aufVoQH qDjw9e/Hxop6fv5S5srnMm9WSgFv5nXgm8Z77/lbBfdJVzjzzT9ua+d+dWIY n94QnTP85KMQt/0CPOPpwD0mKkafObXRUjxYLiouAazaVomJ5EAiquBc2KQw eaDTV2DNgiWFDe6yUDVcWmxFmYcfzZuf4wXzc7xgfk4UPP1/FRz8vLigdMmg GWe6910NeZhGHjR1yfx7CGn7cZFcMMvLvBgKhoNE1FRdNVRO9Pm9fo+fEyNc oAy7XbAKykVl2K/aZYi51tXwbzXN5ZX1oYP6bp+XuEgsXkbTyjSKqkzEyn6B f3hq+g1Ny5aOufau/bdkduDUXb/sPXT0vVeMeSbzlrDPV3zRZZkDLz+RyWyb 2eeZfr2HfvX45/+qLoG33grx0C2ARwXd7iRFoUSW75SwJCGOp7iE0OihKIlq hIQ1Xvn/xFM+B6znc8CZArqOFtClDppxpnZJN4zuamDzrA7nYiE2IcSiOIO3 hYiILlu5j099Rtq6xgn7nskMfKZrLujmTdDrr3JRO6rGnr2IB4IOZ2WX/LDY lNjc2FLlZkWcH75aWKws1W4SbtLESr/CBSurS/zFiuJxl1RX9+iBchxTWlIC YhhMiIUJBJ87dWyInFXGiiwwEmU2OM7KD0SWahInxRN6Eb0C6Ajn6Yyp6Fl6 uKa45L9mqhP/hqXkj5lqDNs5XZNymrkAYRRfdPoFrUNhQRkb96TcQkukRYmu gV9wWZ8cuwC3wLH+55EcvIkktr65dO7lt9w5tfU3GzI/xeeuHjBy1LCf/CLz R7zoksTg6QMn3bMh84ywr2nvnEser6t8vvXyHc29uQm2f+7oEVf1OLlZ0gcs HDZhZW+q02dkv+D/JryDehGfUzmLm8Uv5ZbxfLyyL5cqGsyNkC4qHlo6pGJY 5USuSZpRPLXqVo8rRiPpfJFEDogXgEQBqCwAMYbA3Mk5IF4AEgWgkvqLwyhU ZSQqSAVXGe9n1seGxIfWTo9OiU2OX6EtMBa65nrnBFdq1xrXmtdbV1csja/h 1mu3GuvN261bKm6K321sMjf5SvIGp2dZwh1JhJVED5xAqEfYzffpnUBzQA0Z PVdGbo2QSNxv9CypjOO44BcoHzA+EUp6KiUlfo7VQSfpOFkuWkvnh8wCqdoj uV/E6RmvcBmaUAYcGZElkQenDMcryqENhDLSM+xQbrkzjMNH/KgnK/Ny0xYL R/E43IwX441YxB24zfH0pI+kj4Yej1QSqAfuQYdjaKqoB+2aQa/rEe4D74QT bupu0EPuAmu6qXYz6TnuSZSDQ71nXZyzPaMPU9ajM0JoBUj31EgLfG5aDpUL TMFpZiUfADaxmUCnE0U43eLpX0JYko5qrYrKBCsA+VHZEh9gfCuCZ5GY8axx 6WvXX/XkxHEzBmWuGD//8hv+/rNHf1gj7DOf2da2JTUAfzit9do1J3/+auYf 9+MPrCtvn3rB0iFDL48FZib7Pzrnqt/Mnv/Watdtd6y+eGxd3cKqQbuXX31g 6bKvIKrNdoH9aGJ5IBe+fA92mVbO5WrPA7n6CkIR1sQMhX66/KjW6mVdLs9T mq113EbrdeEVsdM6ammy0ISnkHHWPK3N+of+D+MfLoXXeYN3cZoKTjqvQ5AN EboOsCzqEoRF3ahGUUn3wiHCcbTNx2YrRXndC1cpJYIglzAHfLGjIFn/ygGd RfZhDYIeDdggiuZI3IRx/AH+U57bmMtgOdo4vVP6VOc26lin+5YpHZDIjVKr RKSfmu9/wMYrWkKwwB/47myo9AgKNjaEjzQebqDjGEeo856kg6PgK9AtLjgU 4Be4wD8QclvQODnrT0Pgdt7kZGlf9ij4Bd+zMBcvKYyfxzANTcs4TxlHXQCO 1P2OTPv4qa4Ht3yI//f+YeVFdTRQw89nhpDpeNPea26/jeqUKoja3oWozYW3 O4a7g7wuEzfu4w7QmVtvOwoA+LwSNo/rRWckAD1IlVJrpXBKHYGHkWHyCGWs NQNPIpPk6co46wo8i8ySFyjX4WXydcpt+Bb5VuUHfIxEQnIC95CTSkr+pfwB lmic8azlqycQfIO78K4TA/VKBioqkVU1jgm4fwRTgpKZQlISRXWmgQzKLQrL 9SRdKunAZrssS4L4HLkYgbNLh/ZYbrXc2OzCyOW4ml2trqMugdWaVdBDrmVI vQHj7QiPRVehLFi6ILOlIdNaVkYDLlo3k5+Z1UWBw0k2Xmp10RLFBuszsAmf MVOQL2SwXC8n2cRlOjxKaQDh1W7QYjItGc1hT6a4hL0Xn6VYpKhkJ+KWJpxm WQgZAi+TIiG/+fLZSEqR/ZFzaepuZyDFBgVUf4p4YQn7T4dkdX2xGKOpTSz1 qyvzVZHHlk7LjOVmd/3mqpUL8N/u5mTx7mu6LrlOeZDSeVVmPGkG22Ghcx21 0sTIckuyZXXgul3oYZcMW8eWHnZdgjiLi3Ic97T98w0sAu06fsQ6zmb9stAE J4hd379f/zpRoiOeFsaf3vP26OnPr15ZeW4M/KnM+Ofx99j17UddJw82rd/0 3K8zpZnoWc+f4+hVpMoiimph5FZoD9SHOdCude3oYe4SFx38ytcIft+erxo8 zJSni47MmBCyTzZdpS7ietqd7yPFx4/66Ykhm1ZvJirraLmbRbpWA53Kz628 dvXz00cfyIzHh/Cfn9+7af3035/s+ujbzN8zMhicyWBhbaGTjRVOzmcx1HAJ L3hLDCOgFEpuFVZVyXxdG7ERPOTP+WbM/aAlevtpUjc/RSeSN3Rn3Sk3sKfQ Ifx87du3uUJNuGWuPJcVCSKLsWjhlqfv2S5GQ1YR5RHwIP8newj5YXHDYkIk exkvriXrtHXm6y5BkbQgGeq5yDcyNDgyyTPDNyM0IbJQWqjN8lzhWxhqjqwk 14jLtWvNteJ90ibr9eBH5H3xfe2PZri7u0sVpyxW34uOWVkKUTaW2kvZKLML WqOIfupgY8mrt+VIcYTNB+menUSL3BHLyGGWfPNYbKAC/GyLzi+rTHgsFtpa YKAkcfLCdzYv37nsggXvbHl35V17t61atW3bDatGpsk7mMfnPn3prkz2o0wm 89Iz9z2Lf56597ujeB5e8O38NcDh2T9n5vPrM38DqQZzjhtpRgGF+MHns3RC IZvAgbyU8tsy83/yE1phGwZP1wI7pSIDJ5x+7mn6PP0BfZv+ui5cxF1k/Izn 3JjISBc5CcJYTkI6UPgNjvdyHM8ZiOgGL3HPkecQMA/e7KiI5+EU9IbKd5C5 zwqC6hSX1rMcfT5p8HkhV5CbLq524P6OITnlsXqptayvtNEkuYydtx4Ri0QJ R3J5fWY1D7PqbrLb1YE37KDo/oYWdVB/gbmuDdbnFhuDB6V1vKFQsrA2N4/U NM1C3tMAVeNOGVTtanUprrxniuOLixtyeR5EtZLj1R0tpbeOS+lOIqWXF8G2 Z37WKB1OwXVslglnY7Kp62by85++8kp7pi++9JfcnlMjf5nZQnhyT9dCwO+F mfncIf48kKci3M+5QyNJUh0cREaRlbrY6GsMjQptLNlcItR76iONJUM8QyIT PRMjszyzIs0lrSXviu+5Pxe/0r8OWj1IuZ70pUhffQQZpk8n88mH+h+Df/V/ Ffo8coqYmDe84SJNconeIl5DroCrDtGRPhNbpmM2m60mX8KmjJSwkNVkI31m 90ifyUb6TH++xj2TC7RMPx3pMwvV9ez0RjY6scz+95G+CjbSx2aLSGy2iOTP TR/OzdovLjl7nsh/GOXrovN7fjwlE7VgOz/Pu19+YshZ43s11fdO/nXmu6ve ueG3LY90lT29Yunj25df/WhmPpEHjcHnYGlz5qbH7zgxmHtm//6XXn33/Vcp 1+8FcVkDNp/O5hvgRHkBiZJCxAaea8Air5KGWjoLkWrtLXK+9iI3XdQ6Uhge 6N2LTZyDZe/+/fu5pv37Tz2xfz/c2wcatAn0fASV4t7O2qriAcVE4ZViMtV8 1vNs0aueV4u+LxYx8SGF57xIEUQbKbJkIUWTrIiqS1bQMCUr4HKLdsDl4bwB l5/4Aq4Q8QWNMPFF1CLOG1GLOW/QKBHtoFEq2hFVjUTyCVgjGIwHXN5AwOUj cRBTZElxW+zAe5wBLpdhqKqCIsFgIIBUn9drW+e5wLvgyHko+DMj8DMj7nLs 1FjXw2Bcri5TfxZRfgb3pXMv7BQbpiRbdkW3zcsrOjpIVNgea6B+AlufnTPq YvO1amFNfYa8u5eTx7P+UVWZbgl4Yn3rPGDUPXUcXUDKOIjSuZiH+nWessun bnt1ZOY7XDt101Q8aOq9U595cxT2Z96aumlK5pWpV+OBozK/DeEn78EL78HP ZCbS5Z7MPfdkpuAnM1NIIwaZzD4Ctm8gG4two/ecobwQFwbxdcIaQQjIgiDx POEFD8KGRjivDtZQk+jMTU2UimxzoxcDaoHLjbiqbtRwqdaojdU4jWYn+rNJ jax6WWM5VY1VL2slrJKFFVprMqthYaPfWsjjfebH1crM+aIROatJRo2jj+RK IN2p7nmbdl3dWkvO5X1csmUmZEuNYMUl5coXaGEyZU3cn0kJzZ1KID9r2jPz yvuV9u/XXnf+vSP4r373ux+uu9814m5+xsnNL4+eTT2kxyBmoVlljc4UNOh0 So+vnudKFHWzelAlqkCIJsuCHJUkkepvlsPoTiOL7JVFmkZmTqWIWS4j3Wpg g2jR/Ch3LoX8XyR55HyS54ycmD+XvtCjBo4a4ww6JMjTdHK65YzSNfbVltxu AzMGwIepdC1LlOU+x1IGSwzWj71ITrz4Ypco7Ot6nEw/MYzs6hoNfdwEWJhA sYAzTglX3j8lKwMr1b5iP3W4OpVbw33AScvVD7kPVY5+CsJhCb8qYQO/XniS /1oWVB735d/niUIRobjL6rkoXYF3u0tPuWkr/fiDnN/SQetdxWzbucvtp+2f OOeG4Jnx+LmyEgqdS7/moCqyKnA8H819w0GRgQTsuw6qigTCYyJpMpJVjmgY gd0d6Ji9BLxZaBM6hUMCL4yUaZvWS8JRiM/aQFd3kDWOrkX/bzNIfy9kkPRB W6lSLKTwu+jkDfodD5D3hoZcHT0s7lQtFXlXof6VWmFwuRvkBgjoghDQRViC l8/+YUBTzkGkO0d36TbF11EnAIBIZ5vJlsuqVyikWoZVn68KaMoFHvmow7GV csBbTSjF06U8khIAl3v8APpzg2uaOyWXe1O8401RNO+OA+jrjiboDRGLS5ak WXFt7iMNZRj+JHvTi+QPWOq6n/wki7qOHwWW6UE+6PrVqfvI519n+Fy+mO8C rjFQEO10aubYC71klDXKe7F1sZfX9BI6kh0I5nKe7oTMMnoy82xZ2XqEYlgO R8MY/sJB4/82FfrvSb7QmUm+fJavJX08P8xSyO0xqQCXhyV/6WwuUlZmA9yd 9yU97h59xd1N32Zez6zD1z3/i/RFvW/O3Crsc7nn7Fn0XKar62kOb7hxxk0+ g9rVLSA7z9AxF1SOTzllbs2F3f2KppfOlReV8gpz6mW2lqz8JMdOxmRG4RMq egHQCoC7I/uXXe5wvZt+NqW8st6m+8WV9VZ+a+a3cPwPu4oTueNwvpXf0uPO CADirpFFI6MTtRlFi4qWKCtcK81b1HXmvcY2s8P80vWFabl0PWqbXts2bVNX 3BFSFvarotu2DF0IKoo/EA6VBKgGY0EKGNCyckbPYNA0XXJJwvWQWAiPxAKp mDosZ4qRVXSI6WjF4orWCq6iPPjf0lj8d02Yp3Fs0NZ/S3fnlV/ocPD091QY rZNwrCFVyyocAqm1rnOSAshjbgL1Gf+oDDAPWJUdM2VaA233QCobuCVfMvCJ Ew6lbJA1NywupyhlgVBZ5aWwdEtT0xnp4YAfbDp3DgF2ijHWYp5b2Ray/uW3 rn3jndFVky/KHntx8pVTe5aN+jPecsumMfc+mukl7Bv72sqH3i+OV4y5OtOC e9+8YYAmdV3N1fVfOXwejXbQIyBxXzJrdY/jYyML3cMKqlKiIZl9paLYctdL k7iRUTVqEDVs/BejDP/nxLk+6OIz69S6RxeOHU7+OGN+5ghDme8RvuLUL7jk qfe4m+koQ+PTGeMZ+g494B3a4B10rO9wu2h/TcOuvxAPly9UOFXWlMKQpEtH LgNrJTrY3xKRoEZ4WNfL+ZHG5FM85gjGvKLysqomwJ5UqfgHFatRzHuhXa3S iuoxXclUSmDL0/k+HtoKlwglkkg0tUQHG/Ic3g394vFuJ4KkXrIjE3mk3qhh LezCSBDHo5BBK84ACaNpYoi+fsPoY+C8H7ZOdeMA/D2mmdnofAvNE+VLY17G S5rYBzuYxlZIeVkKB8tY7md3KEWAoQqJnX79c4mdMl8P8t24C0+9zYdPvd7E bW3nnpo98plnTkmXPwP9/BSUzkmhE6LX7U6UcwB3C/kbyZ3kfpl/mscKEgXC KQLWCX5DzTkfNIpHeV/kUKEUPP8ZFFTEKO/KM8LR3DzgQhaCsUBYFxzDzBWh 0Ngf7GxUcAQihLR9uAHfgnJD9y3Js+pSKaOAzqWSVxg/KYtBVCP17devfx05 2X7+O5Pu/UvtMv6681aV/mr4G5dS3kDZL0gK4ggOTdyLOIhYvSn60UEn6k3d y2HCPcxt5wi3HLHRboLhPJX7EpEvcQfethv4ate1QTrL9xjELMwJYsTolngf /fzQto2ZaSHhmxNsvHwx+gs/iH+Jfsnd0e/kWgF1gsjJRHiOTIdGjkzfSRxx Hx4Hgf44x4eewk9FeRKW+QaGzqulqdNZWNBAE/goVBsefQT+BcNWLmjKzdD0 9MU+jH2LuTdPZThCVm/FD+zKvJz5za5/60EruRP8cII5SSC0B8CU0APBwbQH Qq4H4lNRjmsQUViOCljI9+DzNDy/AYwcdOE/9ADjvvSPH3SqL4dPZbk3yerM zF24ETfsysylvZjO7cKVIJMCSsAzBA4L3xLErY7ijYDlBWLLE+wtaXoH576i 4qFBILfunP294Er3P/+Z+ZZ++TL7hfCx8C5yQRz4hjMubGKv5fVGApEIz1u8 VwtoEX5bYI/rFRcXCAQjJFrs2GM9YwNOeJowTZlqTbYv9UwPXBqcEp4auS1w P7FCJRznLtEUXyIqYfbNjPyXN74tfGfjaOE7G18Xvt9zrPD9nhNOWS4Wby3G xWaC0itnVXKzQEJFhe9S5j5MmS6MDY4+K4sF4ZnHQmV9eDpEzCoz+uc+n1dP IBRHs/A63O9NPOyp9syeFw5k9m19DRd/8EccWfnVXW9nPiBv4EX45y9mfvmn TzObd7+Gp/9P5l+ZA7geR3Zh7aeZzwBnbH4Ei8pd6Bandql2k/ZT7VHtqCaA M04nBQ5Tp6hz1N3qX1RJU10SjdalBlEUXLz2lErnUsSEBp4F8KvBERGlBl4d oA0UavlGntDS2y1mIZhvoJ+CYpMoaLaoq4u5rnk+oXNcqJJCS1oKIX735Ir9 +ekVhXi/MMkCEPoQPJLOslDw9TvcWiHSkYO6P/9luDIKyYTjopIMzrtMJI6T FZ4QRZJ5LgrvUajNEbqDKoGNwsH+v5wwJZiQjmo4qo3TmrXFWqsmaDLYM6bZ DHjYf+dP8P9Hf0Id1HSmz5j/Auaxs2IpNt86lVrLs/x/wW3nsoeeBW9djur0 M2zUNaelBbTWSnaGsW+q7RmWkp0+ObBPSgJVT7XZnhCAfXIgbY3ldJwWS0ku Lyweun9sjwfA4hxYDKCPgt/v6HY38GnXhboedZhGeNh+6FWO7Hv1VEbYd3I1 f+OJYXzryVbqpS7BW/iBvMiyP8OdSkHEvKSgOIfjHJHiPC/GexH8MDlACHlB QGEFh2SqWbqTqBDpUF5pYOzCRqyAXcBc0TJrfuCpAdxrdOEu2dr14FbKGQpw xjCaY8Xn5TPqbjqPlcUC3ZN4a8+cvZufnlpRK+BqVMXF1Vq9l96s3yrfqmzU O/WjELvp43RQj5qc9xCeVbAOPg8rRMq7BRWqokRlwQsuA8I4SgQvIYICj/oq qiJZmSPjOURmydaq1DgZt8obwdjTsTyDOFWpSwm+kzwMKKAtdlQYJ5BeQrOw EWLKo4IgdJB1u7RmcD9DVJyoxaNL0MpZm3DoSLDxR/me/CCel1b6IFPtyP7v TsWN6Ub2Ajm/zVetwmlVcFq/07U/TUz9pHPzYnGu2AeT87te+z2+/pzS8p54 wytdLwKNP2hdvGIF3yM31+o+hESTznkihwuV7TL98iyVANll2CydDKrTZtL1 rVNFIT0nbabOKWBSZUVzAZ6Iqonsm1VWforSiT0sQLFQ7nMnuUl3BWk71X7W AAgrZ+/stA4e7KQGKJkfLEOFAZFSidWcimzNsTXP1kI0Hxv+3YmxojwW6XFM XxPX6RFjVc9/Q+n7wpcEvndKKZQAtyequutNthJotZoLGAQ45Mxv8+XmcKjP kSnIDbia4hj5kFIs6IbcVANM3+VYLagCpgQaci+TPh2B54QvGXFuRMQEgkZk frm+Rn8NUKmP0EeYXA8+btS4pnEX88uNFa61hqwRQU4Z/VxjyShuiOTIo40L XOp95H5uk7RJ3so9IYluAlFzL4F4BYHIumH0EmQAZX2COYF+nobI9H/yATXp clmUTs3uVjdx7yNbkYF77xSiwMu9HVVX1Kij3wge7D54SRfW4AjwtOYoJihL c7GFrQ4y5dko8DYrGSdbd9lUDVK+PpZuCIIKZGPXAIe7dw6nUZDOHrXO+IGb ceTs6d3gbvw/7X17YFTFufjMnM2efWdfyW6SZfeEkM2TJIRHHgTYQAJihEQS kCAYls0mWUiyYXdDhCpEK9Y3aq9WbRXLtbdqFUKCGEALKtVber3a6qU+2kpb q7a3VNpLbamS/L5vztndBLC39/5+f/z+IJuZ+c7MNzPffN83zzMzJ/ni+kVi GP8cdPAkYeMnFUU3QFg+V3QjNGcmHfoqLyjePphdZSrO5i8pDlZUmcorOPjc dPCdHr+BMrKZ32C5rhXnW3LNyLbkWCi0fQ/RafTasvSM2bSNphwZW7VvbDVU kT/dd0XTN4UvoCn80eezVac+l+T1LlUhH+/0+AyUqQR3CtHwgyrsu75UkQn/ 8ITps4s6FPVF29f4/l2YJchbp7PTHnyZ/STl8N/+C0fzPTBmOgQj3lxq82Vm 2bPS2Po8ep3GRq3CtGkk2+pgucTN7yLySfxIHlU73CYh263WUurNy50Go0GJ SXnr+UujDxPbXONvj947oGx0VdZbWGQwj+ZN4Ztb+SBfl+FVNqPg0GeZMg5a x1dk8RaB+F202DEmbuaJ3xFRp8rJcmW6MlxQSb3m3DSvx6vJVXlzcp3GKdkk PdWWDch2myTC09SU3Gzq0juyqd0CllubnU2mCWARpTvj1/PE/wr5VRN0dq5l 0p3g6Q6xhOH9EqI6zW5V4TFwi3AV69k19ubj74ztPjBCm97fTen93n3ZGw6G d748kF35Ncru235mPlvwDD1/KhI9RK975ySNHugc/aeyvsFlV9/SeNvu42N/ HfRXUItyOmgxn51uPKjRVguquTBR+3hE3hrxsc8EgCoDLAEtvLpkxMlXNt/x zQVAlQ+W1asq0BTqSk2qLtql7tL/Qq3C7eRqjahVq7VqQasz4N5JSae366Cd FdRagR/2Q1+QJbXjORCDXg3zW0L1oyzDp9XptDBzIBrTKHP6tAbtCp9uEE+C wJTVqNcbJCKsaIQpIHZcz/lAMZRD5fzeca66BkVvf6XoLXMeNJpezsbOTD4t jqeo8MQZdz6Sj4mbz/I2j1rxdSI/0p/Ct63ww/24WcUMVsOQA2q0C7epaAxa g+rw+FkYGZ3lhzJa5fdZfN7LVyrBqPA+2YzkqQv8y7YkOzkLm3v+R7+n2U31 C6+jrl+df571CMvGFt9wQ/Reuu+LkfNfx56uauxqdgPUmkLyFd+yJak035oK A3K0RKfeNCvXClZ6XjopKCw0eHIlmzHXYDEaDB5pb5bVkpuSUZ2V6xWqU/YW 5lV79xYWtpFdMEQKFfXJL3mg4B/i/3k+XlZe78i14LR8iyHX2M22+cxaMZ9V zJk5Mw03WplFtbw1EI9NoldeCWNeb17VMj+MRLQzrqj0rqr0dNXprdes6w2o NLVtnsoNxb6WDCb5l7F21ngHXT67pWOeWfdow81jf6vfFJte8uJPX8mtm/Oo 2dH5GO26o4lh6Uuh9BFe+ptwFPqHESh3wajsemHUPQKl12AHXwWAI99BCig1 SrnZFlOu0ZYtSSbjXmtmtSs3z15tzVXnVefvpapq9V7SRAdhuhcq/ubdfMJQ k+TChxdxwRLnQpqJMdHERHVOzmz+hrICJg24CS3P6+VeDjezpqezyAVM0JrX r45elyJOZAJr/2fWdPvY8OyVwXlm/aMNX/3bovDO3IrnfvqKd9HsR83pXY+N PXQ7zMXJEuG3bHnKD4meOMj7vuW7M/ZlsDOaM3ZGNVB9TomnbOxN8U0bOyYe s7EhccjG9oh7bOx+8X4bu1m82cb6xD4bC2qCdtasabYzu00jOlINeoHYv2fD SZXBmHrOZDLUGKnmeyJ6lFHhHNTAGkpNqTUGW6U9z+iYbzAYfY7MWcZ+xoQa IlZq8gjuLt/oVCbMyozrsyJcKuIwP8aOh9jjLpXbVJh+yROwxB/MxOR3WnZR nojNnABf85Kn6NriObOFd+KA6q8//s6tc68uWJLe1pyEcOTfLPwXWwPagrx6 x7eW8+pT8VMb+0D8wMbeEN+wsaPiURvbJ+6zsd3ibhvbJe6yse3idhv7XPO5 nXVruu1sjWaNnRk0BoVXhlQ9EYBFwBSTkVFgFAFeIaNKbWFxh7hLFEQKXKox GQ01qakmZJOpnwKLahglNYKwC2YCGZxPuA2S9zaoZp/xSZcZDzBj13naPGmS mmQUcGfz5gS36DqaloOaV+GAGpg9Aab2l6TCa4srZgn0n+KQ6jgwqKapYLHj 2muS0KTVp6t80yidaq8iYB6CiQS/JZ6RLQKzC9AQxxeeRulTz7NPKI2vO/Ht mxctO6XwZaexa+6jT8oLT5T4hAD7D8jJSW71XQnDNF0WzdKpdFoDfqFRVOsp c+KXpUSiEjQOq1EU1Sn4rSn+qSmjQW9XiYKG6tQpekLMkp3aj6pTiP476lH6 gM+Y8h3is9hmkYyMvrvkfn3ZWeRnzfl1NVWleJZBPvDH3cQaVUW6w5s3Uy0i 20TcOpqHmlbh9ZXsvsJG7xPsnTtLdmybF76+uvHKyi2x8ptUz95TWfBcXeCB WcX3FJpm37ay8ba7r1y5qyQDW6gaGF+JKceIm74Wv8XIYjY6bTa1/NrDYuHA H3xafEFsdNtT3PyOLkRwuzHU7TJBiJu/NHaPsiM+A9M5HJLHbGFM8uDA5O3X 0X6dlOI9gkX8NsHj+KEAZbqJGRqsVvk9Cwx8Yaqj5HPKp7fa2Eq3Hf0w7WFI Wr46T7kHgK+GXio3nNtgfpgbz8w3Z27KXPWRlKPqI+Jrmh+6xKWGVkOLaZOh 3bTNus12u/UF628yf5N1JtNwVP+8jWWZXeYpZrdZ/f3xM0QcPwVj4zNEO37G l+nWmTVq9QlXpt3lytS4MgWYi2W6BKMbRupPjDRaqGWUOp/DEhDOjlTKDLqo 4y3gNu7SokfYTUQiZlrpM1ieW8DaWJjtgLnyYTaNeOiu/Xcq58p4BTur7HXH a0ktcWXAlyMmZUMqaER871YlduCR1tbctGwvtuxzlD0o2Azh1V92HIqpRZX4 RQVz5P7zI58++fBXbv4WPWT764/f+uyK7768Z6372WdrawLHth//Tcemr3/r Dtsb7/7u2dVPv/DEbf4ZoCkRclpVrToIrVOlz0N6teycRuhNEdXaXqgP51Jo 7wLWCOOaDIO8GnF23bKzNdB0flhTQ0rP4rXDM8pycQ3CIr96YHRsM931NN01 tvk0vf9JdJ8c64V87hwLMSffm7zYV6QSiigzp6iLiGiF6iyq96pScilRyy/h tVq2Ekf/z2geVTZ9yPcby7s84gdQbJBfjmVm2p307nffHQuJVz9w7t0HUPfz xkL0AM9pgc+hwo2sZoEVEWpVp6RQtlcl5OIdh7/38ePg5BntN9fw18qXyIJm z8bLd7LpgbHou+/Su8dCD6jzeB4V4x8Lfn5W4ymfOcg61THWr77NeJtFreVz hQN6nCqM0kyfXuVO1Wq9Op3Gq4/fw8gBZWI/Fn/z+En87pExH9/DpF8n2ahk 89mabOttKhv1EnlPlPzyID7r+Zky62mwHowvo+GFFPLs5zRfajx9umiB0sQk LpOQL9Ccu0/sCyzdmP9y60s3v/Q6fdz55A2LotuFP32RMXpi4y/iq0hLoZw2 9pyvwGulGTRdzwqsBbZKWiFUaiq1lcZq02xrhU1nteGWAytaJmWfgVFxJ+4/ 8HXjBgQpvkVhgA7oGQzXxXx9oclrnaOq1lTrMcUrNC2qdZq1+jWmFmsnDao2 ajbpQ6agtV+1TYMnHAasA7ZbVXeId+geUI1qnre+qvqh5qeqdzTvmk5aP1Z9 ovnE9JG1WM3fshiglTGno63XoI23rYwgkDynmmY3O3WW+DlVhMz8nKpGB0OO i86prlPLp1T5GVWz2ZaKh1TNZqPFarMlzqnadHqqNjObVmezSYlTqkZp4hFV ZuNHVDWlaTTN4ciUDD5+91fb85LuXt0xnQDzi9Hn2pQFsVGfTn3AZ24yv2EW zIDk00kkw56mzCGWn8VTdOucv8k4ve70OgD4QboLz61OOjTHj63yg6vy1WAT HfnF2fFWvsQivz1KLLrwxQI9LphmVFF8HevMqrLiRuqsKpvs4IUNB7NgtpGF b9mODbuq+Hd5PK4qm89VJYAxmtIdNTZrumOeRguQAPPKefxwbAlMb6daq/SG KdnzKJmSXaPXIcQQMtgc4GdzgB9CDKBJb5GL6AS4leL3WvDYbHxiEz+kp2UV Y4aPqa45Z8YimvfW+fOs6MzYLk/2jLSxe9kX7Ptjt/UvaLqG7jy/7ItzTD99 dpN7DO8M4LuUM7BPJYV0r7IAqvc48YITp7xEoV7pjL//cOKrvHyspE4L70Mt fLJvcVqKi/T5btxJ3WgSTCY7DPopX10wmkHtqMrtMk7FTgZH+seL1pXj6bHT 5cpNCUW4ImZ+/e3XzT//QaKnnUDE7/jyAwK+QmxfIG9+58Wlc52c1wVZlU7M yDerOvOqdF/OtenX5HQI3ek9mZ052zJvdN+Veaf7kfSnMl/I/F36R9Jnkm1e +mPpz6YL1QXtapaH1wPk4M6sbEkt5bsbTW0mZjK5MEv6VhPf2Nd1AInwHKZV RA9dp8XJdzxDcZxmJ3PeWwxNaOUB8lxu1JLY+GzxWZjl3qLExuezytZn+RNM ygeY8O2R3HluxpUquenD02F5avm+bwJ9Jwzm+Mc26KzkR3z6nk2/wd98Y9Mc OudIz8EvqPjqrtNf2fbHPc+8x370ndj1w0/dcOO3abN5W+9VO97pMzhXbaKa dz6g5kfGfj32p7GPx0b2HhVmffPg8W/dtW8ftp+oM9kp/wLjsFXxFWG87trI 74FymXTutDSXFYcT+lQVcsJEiThJjrybcOK4p/T1xFLQ+eNmPAGR5SuwyndB c7shc+uUO6Y8aPuu7RXDScP7WRqtzWkqzBS0ZSllepSFALIw23Rp0EydMKXa TTa7KdUIoxufDQnxmR5H8aT6oDGSiXo+VUXfwq/swcjHJyF5ljZz2LzDvMus Mg+K0cnCAs1/nmv+vZL1BTqbpNIHiJFWDpueo4dpJa6q+/TJjeueUXr//qQI +cAIpQhTkYlytICByceHX9PIO0cIHxxx0fIbLFsTV0bLYyIbbtuUv76B+w+9 K19Me7j75gPP3nXNXflP3cPePf984y33HaOa2N1n//U8HTTfcefxPY8MNy5I Z398ZmzL2rHPfvzafcOnUHKrxj9SpUNtL6KtyoBWn+Hk+5idLsIrbBHeRUML cnTGVEOqW6crSHO7VO4CV0qBMcdocGZQYpX49kRJ9PKuG9C9pbhCj7IEaVqr FizAmRVO6F81v2qtAqmWo0HR5qcY0431xluNqnrLNZYtWcKK9G7zRnt7er9x q/1W4x3227O+Y9SlSPyDeXr8trxKpJAvxeEqCu0Ixc+BG+lsGCqkqZyH2RMk g3X58oDKFCDTaI22SWGJSfzzLxKI08vF6aV4KzPzxsXpvXe6EyrhcMZblxJj 8WQxxoXIjwqfjl+djKfpPkzeKA7S4/3J5knCEysmyjH+MRx5OYeAJFcd8Dyw ace+PTfOvMpu1UdHb90Yust+IPt3e68/samj/eZ7xz45+dI4/arz4a8N3XzD t+2PsetvDNx8yy3Sc691Dre3favE/eI9x8b+/BEQvQzqZBpIFk/ZNiqy9aRS D22jAs3Kd/uM1GiEiUpWCrRURp0b2lYzv6AdhW92O8z8ewdcsg6+rOdQXrxg c/mDeB1dh99OQ0FO35RB60RfWl1GnbTG2iJtEtrFds1Ga7sU0/S7dmpudZ3U vJ1uEfnFQnnx+4RyuFgRypaU9+mnDuRJOVI2BliQyiYjjCfsWfStNrkp9Wnj NGOr6bNis2nmMjVTYoZxJ5TiDL+v0nxvsQ6F6aZVvvQFjjZH2LHDoXLwYaeD b3h1jLJpI0obi5stE5JV5MrlmWxmeeeLL8uoyL9lhzMSFKFV+QiOhX8SJ53a J1RW4fMRZ/HSTatqV25gtS90Hjg/8OYtvxz78NHbP3n25+crGu9ZHnliz1e2 Pa1qNm0sW1Y2/w8/C6wf+8tP7ji9nTbQG+hTLz358hc/X/d06+hjD0FTi5/w FAjxeFoeakut+bMmS8O/Ur3n13mF8S9W4w5scUvK2wBqOT7/jDUh4vyx5WRR 8sPWk79zTa5Wg1fKa6RDFSVfA9OgIqQJzG3Kcx19TYZZFZkG7kL8FjmELwD4 SvXTgENIJphs8Lexp8lOwP8qwE9D+K1gvgpmMTwfVv2alEE+aoCPAn4q4NbC 87fFu0kGuI9B+JMpq8iDYNamrBo/Dzj5gHMDGkhjpSo6/ktwM8FcAWkcAjeN vja+B+I+ocR7DNMDdw+kVQDhH3BanyF9aOjXyBp1FQkgbYD3LfCLAK4WyvAQ 4D4IYT3wrGbPkCowpZDvEjDNmIYwhfgApwbjwPOdYPKAvgqMj7TBbxVZxvmZ RobpLSwgzFPdnrJJfZX6VfEpzVztTO1MvWjoM95m+kbqK+Ye8xlLr+Vp68O2 LvtC+3r78+m/d1zn7HN+PSM3sy7zk6xFrtQp7e4qz3RPj+eY9Jg0mt01deZU f055zven1eauzf0gLy1vIN+RvzP/xfyxgtqC9oKxwnVF5UUbi6dNPzR9rOTV 0ofLnGUPzyidcXzGufLQzO0zh2d+PCtj1t1zbBXTK3WVf6n6laIJLaQS9Qq/ EkvMpBRKQVRGHZ5hZOC3WFgu6x38jXFb4PF0/EngsUxUo8ACuY6mK7CK6GhM gVOIk25XYDXgP6jAIjlOn1BgDfGyLgXWkjvYPQqsU70sOBVYTzaI7ymwgXRo ahTYqD6g2aPAJrI2dVVCx3ekDiswqLh5hgIzIprnKLBASs3zFFgFON0KnEIM 5s0KrAb8GxVYJBvMtyiwhtjMHymwltSbzymwjvkt8xVYT2bYdiuwgcy0vanA RmGNXVBgEylxrANKqAq5bnDcyeEUlIjjGxxWc//vcljk/iMc1nD4FQ5rUUaO txQYZOT8sQKDjJzvKzDIyPlbBQYZZSxRYJBRxtUKDDLKCCkwyChjQIFBRplz FRhklOlXYJBR5n8qMMjI86wCg4ykVAUGGUn9CgwyyivgsA7LlbeTw3osS959 HDZw/29z2MRhOU0zliXvEIdtAFvzXuOwneO8y+E0ns5vOJzO/f/M4QyMm085 nIU4+TJtUxAn38NhD4eLODyN41dwuJDD9RyejjUjvxlhDadfgXle+W0IG2T/ TRzmZckfgJq2lfSRIOkgfhIAVyJPgWkhXRxeRsKkF0xMwZKgxQ6TCMBo+8E/ xDEk8OmG+CUA1XF///9lSqUJyiTSDCHdpD+BEwW/peDK+c0gVfArI9MVqJz7 1kKMbnBXQJxOoCHGY62A9KJgImQL2O2AFYFwP2BiSCfk0Q1PkYuorZ6AKV2A Ww2tE6YYTZRgJlBQBj+J5ENKIaAzAiFRMB2QYsGEtL4sZhJjGfAh+bSXcxT5 1Q4xe3j+m8APU/7f81oCXyxRCCiJcYqQNxI8I05MSXUlyEEiTTy+RLw8v2Vg N0LeHZznfsDHeEFIFbk8wGNiaiWXoEmWbxjyRZr6AHfrl2IFuV4h3gCnqjOR b0jR2ulcLmGyQaF6OQ/p4prjB2qKE7RHeEiIa2gz2P2calkOsjZVgg4t4pTE OJfjfIsALRJg+RUdlDUpxHnfzjULda2X5zVRXwJKWn5OG8bs4Ski3V2Qfw9P Uea+xKn28/wCijTkEKQ6qsjDz8sox9uakH9I0fI+RYJBzpso1zy5dHEJ+RX6 +3luEs9hIlVxySNv8HmAp901QRsQN8zTkvOO+8vcjikcCSiaGr0ILwZpBjlX QuDKaQcUn37OadSopE6HeY2NcI528/hIKcqzR4kVzyHA429Rcg0pJZXrHqaQ 5EIHr8Pdim+SryGFu2GlJCGO38+fklKNci3t5tRdWifibWo0URYM6+HpJdPA tmGTQq1f4X+At3aSUkvjPGvneXdyXzk+1rCQIsMuXu/6FB0Jg401eovCbTmF ZCvv57KStUPiPAwo5Q9xqXVznD5e92Rt7OUx5ZJM1O5QQrOw5l+vSKaHU4O6 uUWpW3K7052go4c/JbU3dkFPFL2gfAEljw08hX7O6fZJuhkkm8E/zlnU7UCi hB1ctyWuA9dz3ka53sUS7YksdaRdru8xpdWQa1NU0bJk6ymH9nCJ+Mk2Hl+m GtMN8NCkpsm5t3Nu9fFasjVRinjevbzNxHA/50REyQPrkMzFGI8fpzieeh/X oR7ebsZpK+F9XgzCqqEvLYV08VfCsSa2sCW8deoBjC5el7oB6gGol0soyJ+i pI3rgCzxkgTm/9scBrjGyLjBCbksh5a+Bfr7xWAWgeYh3Ai+2AMsBvsq7l8P Ps1go24ugZ6gHn7LuG8LMeKNB2BauDZFL6FrUsJfricyR/sUnid19B/rxZKS ibfIcTlv4KFbAb8/kWcg0bbJ+pzsjya2lnLLkWxH5fobUtrMqFKnO3kqwUSb iLW1VckNa/cWpS3dkOiN5Dxjf4cz8bZzINE6BZUaF0zodIS3HzGlPnco+ngp fsVrIXIsOCGVZC2+OL92pQdEDdzAW0aZ6g2KZHqVlC8loTxeqsmcklvki7Xi 4pzjbRu2Yn4+BvVDrt0Kt6NKG/JleSP3V4JPsp3depEsgsooY+KYS269/Zyi Ps7ZkDLS+UdkLim62DuhbYvniy1JO+d0aEIvEpkwRi5OYEcm6G2y7/77nELq enj6cb0KT0pvgMt/E5fmxHFovH1MYoYBVx6h9nOOY/pdifLIdE3U7h6lRZX5 L9eqPkU/ki3vZB36eyVK6sdSXvaLJRcfe2GfE1RGaHJp5PFegEu19wIZRC7g dzLlKB+t4oikXemHtvCx0QCZOLr676UfTy+ijP9CylznUqO4i+Uocys5Yg3w NC+ux3GJ+S/gdcf/iNokly/OYXJ/P5mioDKKjUHfE08B5ye1RJ4J5MMYfhap gLmWBPYMeJoOs6pZfG6FqwQrSYOCWQahMyBklgJXwBysgseaQ2bDXAANpv4/ 6+v+9z1jPKz0Au4l+sOWrX3BDn8gKD0ltXQFpWXh3nAMvKRF4UhfOOKPhcK9 Ul93oESq88f8/w1SKSYmNYe7+9EnKi3thXgzqqrKpoNVXiLVdndLK0KdXbGo tCIYDUa2BNtrIyF/94pgZ3+3PxJPtpp7Sopv9apgJIoZzCwpK5Pyl4UCkXA0 3BEr4FgTA7nHshbuPCm1RPztwR5/ZJMU7vi7VEuRYGcoGgtGgu1SqFeKAerK ZqnJH5O8UssyqbGjo0Ty97ZLwe5ocKAL0EoSKUF5w50Rf1/X1oleQaku4h8I 9XZi3BCwdrq0IrwBkl4eCnSFu/3RYkw9EgqE/FKzv7+3HcoAbKosXxTujQV7 kLbIVinqBw4Ck0IdUnswGursLZZkvgQAyx+CwJ5wJCh19ff4e4F8KdDlj/gD UAx4CAWiUA5/rwRhW7H8IWB5HxQwGAhGo2HIDgvkh/T7A11SSEkKC9/fG5QG QrEuzoaecLgdYyMMZMeAkAAwNRr3iw0Ee2OhIGAHAOiPbC2ROKfDW4IRP8g6 Fgn6Yz0QhBEC/SDvKGaG0gtGOAkd/d3dAHJaIfueMGQS6m3vj8Z4UaOxrd3B iZxATY1iLsFIT6iXY0TCmyBZP9Af6IeMZAG2h/ydYQwf6AKeS13B7j7gSFjq DG0JcgSu8n6pG9gh9QSBd72hAKD7+/qCwMbeQBAykdkdQmZJweuhMD3B7q0S lC0KutONafSEujl7Y0oliir5BSDGhqDUHwWV4twMbu5HYvsDyH+pIwxFhhSh ULEY6gkUPRIEucdANUBMUWAZV0947PF3+reFeiHpYCxQLDMNoreHon3d/q2Y BcbuDQ5E+/x9QBqgtAOJsVAUE0b0vki4J8xTK+mKxfqqS0sHBgZKehSFLQmE e0q7Yj3dpT2xXn9PsLQn2ubHgpeg5z8YYSDYDb5BHmV5Y8vSxUsX1bYsbVwu NS6Wrlq6qH55c71Uu2RFff2y+uUtRp1R19IFbI1zDVmMMgFCoQQxztFLVDFe GFRkLPOGrdLWcD/GDKC2AZ95PZLVEpSD6yjIF6pfL6D7OyPBIGpiidQK0br8 oAbhDViNIGZsEjGonQOoTkEQXBA5HQkGYiDnDuBjki4UYbgzyFG4iBPxQDSg vRv6Y5A0kBmGGjWhQHnROFGgyAlWJCKjtklb/N39/g2gYf4oaMjE2CXSyl6u s1vjpYAyKS0XqLdfivYFAyFodC4uuQRc7OXahnH97e0h1AnQyghvkYvRO8J5 y2v3BUR1h3pCWCDIhOMNhCOborKScn3knuEBaFD7N3SHol2YD6Qls7sHFBXo B1H1bZVk5VU4NDkjzo+lHcnCYeu1uT8Y5dlAuxcIRnqVEkQUujlytCvc390O dWhLKDggN1cXFR/xQJJBaAHak01cooxAFm9YA7GkjLFgfoXqjksny0lORFDq vZIQ5OOPVSPCyuZa6ATyK2dVFEgVMyqnl80qK9NqVzaAZ9mMGbNmgV0xs0Kq mDO7anaVUfclte7vVkZ8KlXI4/UQpqphPsnDQTlO0bZSI3T8G2EA8Fs+bIiH NfNhEE4ScdDWLjwi7BdeFI6COSQcFp65vKR/eUmfXF7Sv7ykf3lJ//KS/uUl /ctL+peX9C8v6V9e0r+8pH95Sf/ykv7lJf3/D5f0J838k7Cf418q7JcXxAlO WhPgqwJfkmY31/AJzyq3aoaqQbVENQ/sqkk5YBv8Zaks53UG2x659F10iH5b ILxefHmcS8OJvbxkPA9vqLn4b39Lau1UwUE+BTMORiAesEvBNIJpA7MLzG4w apKq+ITB7ABzFMwZHuITHMP3z/SNgnMnd0Y2dpfzR7/8uHYdfxy5plV2l10t u3VLZbRqGW3GLNm7ZKHs5hXLrjW3fBBdnbH8WG26kE7eFHD3ZR/YlB0nqZQS D3lcSCNDYJigVnx8gnVkmrd891FBRajABApM9YwfE+iw0VJeq2Pj7FNiJR72 B3ZaDmGnR0yW8t21V7JfkX1gjoIR2K/g90v2S7KDnSKUmMFeAGY3mKNg3gDz KRg1OwW/D+D3C/YLksp+TkrBLADTBmY3mKNgPgUjsp+DbWY/w+3A3EZ4ARjG fga2mb0PxXof7FT2HkDvsfeAtLeGK6rKD3GgqFQBPLkK4MhSAGt6+Sj7yfC5 As8o+/WIVOR5vLaMvU2GwDDI7G1I/G0igWkCsx5MHxg1QCcBOkkGwdwL5nEw Q2DUEOckxDkJcU6A+TcwJ0kZGB+YJjAa9uYwZDPK3hj2LvTUprN/Z68RBzD1 dfav3P039ip3f8R+wN0fgusG9wR7ddjtIbV6CCcQxwyuGdxSCE9hL41Ms3rG ay3sKLDHA3YpmAVgGsG0gdkFRs2OsqnD7R4rJHKEnNAQwBwmv+Xuv5A9GuLb 6PF5F4GOSWh5q+cBBNZuabeX+bwPPgyPaHnvuR8gtLy33AUQWt5tNwGElrd7 C0Boeds3AoSWd00bQGh5G1sAAmuUPfb8tDxPReMmKtWmsgHg0gBwaQC4NEBU bAB/5JwKafvmcGEhcOwRX1FBoWfwMB18gQ6uoIN76GCQDm6ngzfRwRo6eB0d LKKDLjropoM+OniEVgIrBqnvwKTHKp+TDp6gg8/SwSgd9NLBXDo4jQ5KtMI3 yrKHl87kTj13RmqxXoE7b355KtCYDRzNBrXOhmp/FOw3wIzzJx8gSVNl5Aw3 ulNHChfIzyXV5eHaK9grEPEVEMMr5AMwKhDQK6BGr0AiuD09FewFYNrAHAPz KZhxhpeSfsCmAuG7uJ0KdimYBWDawOwA8ykYNSfnUzCMhBUS93HCShWiG/GJ vQK/qfDLZtm+KWaXuch8hbDLRVPdtNE97mYVJB2PJ1gtGssoNR78i/GvfzES ba2W3cN2kSkgiHsVd9fwuSmeUfrQsPeIpzaNfoO4VaB1tIp4aS64lSTKn2cT lwbdWcTFvgdu+bBrFURLHfYWew5TE8Y66Dnn+tDzW9coA/AT1xHPT6VRFR32 /Af4fO+g523X7Z4flo5qwOcF7ygF57DEUQ+5Kj3PnuCoN0HAI8Oe7egc9Nzo WuLZ5OIBQTnguig8+VI9K7xrPFdAenWuDR5fFNI86Fngus5TI2PNxjgHPWVA QpEMFgKxBS6eaY6bJ7iyYpR2+YrFB8XVYqM4RywXi8Vs0SNOEbNEu8aqMWtM GoNGp9Fo1BqVhmmIxo5ntYrwdIVdbUZHrUJbxWEzv0qIyQdNGNUwciUZsgkN rKF5IW0YOhYgDRukoc+ac0ap7uo1Qyk5C+mQtYE0tCwcqixqGBXHVwxVFDUM iU3Xrt5P6T2t4DvEbhulpGX1KB1Hr51ZQ9ZFeOKUWnbenYVu/s67W1uJM33L AucC63xL1eK6S1jrFXvCYWrnJHjK0IMNzauHnp7SOlSOwPiU1oahrzdLa1cf on+iZ+rrDtE/otO6+pAwn/6pfgX6C/PrWlsbRukqjkck+kfAA435I8fTuImE eETSuGW8R2S8XIgPeNPQATytluRyvFytluOpKOLtj06rr9s/bRrHccDYk+NE HdJEnBO5gJOby3HSB8kJjnMifRBxhuZzFJcLUNwujkIziYujuGgmR1mVRClV UG5PoNzOcxJoEscl4xhPxXGMpwCn6B/9Cy4sKqIjc1sDa+uDOfXrc+qDYNYP 3bmlyzk0uEGS9gdaMUAaErzrNwS60PUHh1pzgnVDgZw6af/ctZcIXovBc3Pq 9pO19S2r96/1BeuG5/rm1uf461pHljTNqpiU1+2JvGY1XSKxJkxsFua1pOIS wRUYvATzqsC8KjCvJb4lPC/Cdbxp9X4NWdi6aK3sjjC9DvR1fVZ268J0c998 rrxzs53bsw7DgORJoi9qHTLkLBwygsGg6bXTazEI6hQGmcA7VQlybp+bnXWY PqkEmcHbkrOQFMX6o/3EWR+qk/+j8AdesX5kuGwXRb/sD8Lqh3z+umiMkIah wuaGoQVXr1m9XxTBdz0Waag67qfX14+OH5M9S8CzGj0FIYGIfjXop9UqiBfL v3/ibQuD7MgI9bkpzOpahSF3QwuDpqBlDZR17ZrVh2G4hN1DtBUKGKVFNBpP g5OtfLiCYHnjJtavQAofYoorx4Io0Tg7En/IJfJ/AHcFOR0NCmVuZHN0cmVh bQ0KZW5kb2JqDQoNCjE2IDAgb2JqDQoyODQzNg0KZW5kb2JqDQoNCjE3IDAg b2JqDQo8PCAvVHlwZSAvRm9udERlc2NyaXB0b3INCiAgIC9Gb250TmFtZSAv Q0FBQUFBK0FyaWFsTVQNCiAgIC9GbGFncyA0DQogICAvRm9udEJCb3ggWyAt NjY0IC0zMjQgMjAwMCAxMDA2IF0NCiAgIC9JdGFsaWNBbmdsZSAwDQogICAv QXNjZW50IDkwNQ0KICAgL0Rlc2NlbnQgMjExDQogICAvQ2FwSGVpZ2h0IDEw MDUNCiAgIC9TdGVtViA4MA0KICAgL0ZvbnRGaWxlMiAxNSAwIFINCj4+DQpl bmRvYmoNCg0KMTggMCBvYmoNCjw8IC9MZW5ndGggNTgzDQogICAvRmlsdGVy IC9GbGF0ZURlY29kZSA+Pg0Kc3RyZWFtDQp4nF2UTW/aQBCG75b8H/aYHiK8 M7uYSMgSgSBx6IdK+gOMvVBLxbaMOfDva7/vJqp6SfR4Z2fnmUGz2B52h7YZ zeLH0FXHMJpz09ZDuHX3oQrmFC5NmyZWTN1U4wfiX3Ut+zRZTPePj9sYrof2 3Jn1Ok2MWfycAm7j8DBPm7o7hS/4+H2ow9C0F/P0a3vkp+O97/+Ea2hHk6VJ UZg6nOecX8v+W3kNZoHrz4d6imjGx/N08Z+Q90cfjPCDZW1VV4dbX1ZhKNtL SJN1lhVmvd8XaRLa+v/TlfLW6Vz9Loc52k7RWea0mEEAyxVACR7gCAzzhFfA EpBngJwne8CK8AJ4IbwBNrzjAK88yQFbgDDbjmF89I1hFrAn7GawGcOWAPrk eNRGH57QJxdA9NkC6CME+iwZRp8cPbDRB1Vb+gh8LH08T+iTw8fSx7Gc6IP2 WvoIFejj8Y7QxyOBxPkgtdDHwUfo41Co0MejVUIfh1ZJnM8GQB9BBUIfQW1C H0XjJfpgjEIfZQX0yZmaPsrU0YcVxPngROnj8KhGH/x2lD4ejyp9PHyUPg4N Ufp4ZqOPogKNPihU6aMYo0YfzEfpI+io0sfxDn2U5dDH8Q59FPPROB803kUf nLjog0ddnA/ecdEH7XX0yfGOo0/OBLOPZJaQE5iNPp4Qf2/ogaOPolWOPsLU 9PEE+nimpo9jguiDkXj6KAr19FE03tNHMVNPH11ys3xskHnJYC9+rrDqPgzT 9sL6xNaa91XThs8V23c97sU/fwGCKTSrZW5kc3RyZWFtDQplbmRvYmoNCg0K MTkgMCBvYmoNCjw8IC9UeXBlIC9Gb250DQogICAvU3VidHlwZSAvVHJ1ZVR5 cGUNCiAgIC9CYXNlRm9udCAvQ0FBQUFBK0FyaWFsTVQNCiAgIC9GaXJzdENo YXIgMA0KICAgL0xhc3RDaGFyIDgzDQogICAvV2lkdGhzIFsgNzUwIDcyMiA1 NTYgNTU2IDUwMCA1MDAgNTU2IDU1Ng0KICAgICAyMjIgNTU2IDI3NyA1NTYg Mjc3IDUwMCA1NTYgODMzDQogICAgIDUwMCA1MDAgMjc3IDMzMyAyMjIgMjc3 IDU1NiA1NTYNCiAgICAgNTU2IDI3NyA2MTAgNzIyIDI3NyA1MDAgMzMzIDcy Mg0KICAgICA5NDMgNzIyIDYxMCA2NjYgNjY2IDY2NiA1MDAgMzMzDQogICAg IDMzMyA1NTYgNTU2IDU1NiA1NTYgMjc3IDU1NiAyMjINCiAgICAgNzIyIDY2 NiA2NjYgNzIyIDY2NiA2MTAgNTU2IDI3Nw0KICAgICA1ODMgNTgzIDE5MCA3 NzcgMjc3IDcyMiA1ODMgNjY2DQogICAgIDgzMyA1NTYgNzc3IDY2NiAzMzMg MzMzIDMzMyAzMzMNCiAgICAgMjc3IDM4OSA1NTYgNTgzIDI3NyAyNzcgNTAw IDY2Ng0KICAgICA1NTYgNTU2IDU1NiA1NTYgXQ0KICAgL0ZvbnREZXNjcmlw dG9yIDE3IDAgUg0KICAgL1RvVW5pY29kZSAxOCAwIFINCj4+DQplbmRvYmoN Cg0KMjAgMCBvYmoNCjw8IC9GMSAxNCAwIFINCiAgIC9GMiAxOSAwIFINCiAg ID4+DQplbmRvYmoNCg0KMjEgMCBvYmoNCjw8DQogICAvRm9udCAyMCAwIFIN CiAgIC9Qcm9jU2V0IFsgL1BERiBdDQo+Pg0KZW5kb2JqDQoNCjIyIDAgb2Jq DQo8PCAvVHlwZSAvUGFnZQ0KICAgL1BhcmVudCA5IDAgUg0KICAgL1Jlc291 cmNlcyAyMSAwIFINCiAgIC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NCiAg IC9Db250ZW50cyAxIDAgUg0KPj4NCmVuZG9iag0KDQoyMyAwIG9iag0KPDwg L1R5cGUgL1BhZ2UNCiAgIC9QYXJlbnQgOSAwIFINCiAgIC9SZXNvdXJjZXMg MjEgMCBSDQogICAvTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdDQogICAvQ29u dGVudHMgMyAwIFINCj4+DQplbmRvYmoNCg0KMjQgMCBvYmoNCjw8IC9UeXBl IC9QYWdlDQogICAvUGFyZW50IDkgMCBSDQogICAvUmVzb3VyY2VzIDIxIDAg Ug0KICAgL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXQ0KICAgL0NvbnRlbnRz IDUgMCBSDQo+Pg0KZW5kb2JqDQoNCjI1IDAgb2JqDQo8PCAvVHlwZSAvUGFn ZQ0KICAgL1BhcmVudCA5IDAgUg0KICAgL1Jlc291cmNlcyAyMSAwIFINCiAg IC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NCiAgIC9Db250ZW50cyA3IDAg Ug0KPj4NCmVuZG9iag0KDQo5IDAgb2JqDQo8PCAvVHlwZSAvUGFnZXMNCiAg IC9SZXNvdXJjZXMgMjEgMCBSDQogICAvTWVkaWFCb3ggWyAwIDAgNTk1IDg0 MiBdDQogICAvS2lkcyBbIDIyIDAgUg0KICAgICAgICAgICAyMyAwIFINCiAg ICAgICAgICAgMjQgMCBSDQogICAgICAgICAgIDI1IDAgUg0KICAgICAgICAg ICBdDQogICAvQ291bnQgNA0KPj4NCmVuZG9iag0KDQoyNiAwIG9iag0KPDwg L1R5cGUgL0NhdGFsb2cNCiAgIC9QYWdlcyA5IDAgUg0KPj4NCmVuZG9iag0K DQoyNyAwIG9iag0KPDwgL0NyZWF0b3IgPEZFRkYwMDU3MDA3MjAwNjkwMDc0 MDA2NTAwNzI+DQovUHJvZHVjZXIgPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0 RjAwNjYwMDY2MDA2OTAwNjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMx MDAyRTAwMzEwMDJFMDAzND4NCi9DcmVhdGlvbkRhdGUgKEQ6MjAwNTAyMjIy MjQ0MDErMDUnMzAnKQ0KPj4NCmVuZG9iag0KDQp4cmVmDQowIDI4DQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAwNTgw NCAwMDAwMCBuDQowMDAwMDA1ODMxIDAwMDAwIG4NCjAwMDAwMTEyNTYgMDAw MDAgbg0KMDAwMDAxMTI4MyAwMDAwMCBuDQowMDAwMDE2ODExIDAwMDAwIG4N CjAwMDAwMTY4MzggMDAwMDAgbg0KMDAwMDAxNzc4NiAwMDAwMCBuDQowMDAw MDY5MDQ3IDAwMDAwIG4NCjAwMDAwMTc4MTIgMDAwMDAgbg0KMDAwMDAzNzE3 MiAwMDAwMCBuDQowMDAwMDM3MTk5IDAwMDAwIG4NCjAwMDAwMzc0NDMgMDAw MDAgbg0KMDAwMDAzNzk0MCAwMDAwMCBuDQowMDAwMDM4MzM5IDAwMDAwIG4N CjAwMDAwNjY4ODMgMDAwMDAgbg0KMDAwMDA2NjkxMCAwMDAwMCBuDQowMDAw MDY3MTQ5IDAwMDAwIG4NCjAwMDAwNjc4MTUgMDAwMDAgbg0KMDAwMDA2ODQw MyAwMDAwMCBuDQowMDAwMDY4NDYwIDAwMDAwIG4NCjAwMDAwNjg1MjcgMDAw MDAgbg0KMDAwMDA2ODY1NyAwMDAwMCBuDQowMDAwMDY4Nzg3IDAwMDAwIG4N CjAwMDAwNjg5MTcgMDAwMDAgbg0KMDAwMDA2OTI0MiAwMDAwMCBuDQowMDAw MDY5MzAyIDAwMDAwIG4NCnRyYWlsZXINCjw8IC9TaXplIDI4DQogICAvUm9v dCAyNiAwIFINCiAgIC9JbmZvIDI3IDAgUg0KPj4NCnN0YXJ0eHJlZg0KNjk1 MDkNCiUlRU9GDQo= --0-1698605415-1110428918=:76477-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 04:35:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 193AE16A4CE for ; Thu, 10 Mar 2005 04:35:41 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A66BF43D53 for ; Thu, 10 Mar 2005 04:35:40 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id c51so331941rne for ; Wed, 09 Mar 2005 20:35:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ExPUUsn9hqIyizxUap2MkAVevQg5fJCtSfpjzrIfoUTk+eGBwU8IMhoHi8vBHYu8xd9A2YJZaJlItbnQWdeC801L0bugH8TOPl/EPx5J9GLxemERPWA/n9D+bRcGeIJDcfNZ/PRBRvIDDpIdv22q12HoZhStuehIYIpviFolrqs= Received: by 10.38.88.22 with SMTP id l22mr1508819rnb; Wed, 09 Mar 2005 20:35:40 -0800 (PST) Received: by 10.38.209.22 with HTTP; Wed, 9 Mar 2005 20:35:40 -0800 (PST) Message-ID: <84dead720503092035629ea5fb@mail.gmail.com> Date: Thu, 10 Mar 2005 04:35:40 +0000 From: Joseph Koshy To: William Bierman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: cc: freebsd-hackers@freebsd.org Subject: Re: Can someone please help me? Why does init fail to start? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 04:35:41 -0000 > execve(), and at the start of init. The kernel print statement is > shown, however the init statement is not. > Any clues? 1) Does the execve() invocation of 'init' succeed (errno == 0)? 2) What is the value of 'init_path'. Which executable is finally selected to serve as 'init'? 3) Does 'init' run on a regular FreeBSD kernel? ... etc ... -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 11:38:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B82D16A4CE; Thu, 10 Mar 2005 11:38:48 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E22AD43D5F; Thu, 10 Mar 2005 11:38:47 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id D4CC0C165; Thu, 10 Mar 2005 12:38:46 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 79A85407C; Thu, 10 Mar 2005 12:38:43 +0100 (CET) Date: Thu, 10 Mar 2005 12:38:43 +0100 From: Jeremie Le Hen To: David Schultz Message-ID: <20050310113843.GJ34822@obiwan.tataz.chchile.org> References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310023518.GA11712@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310023518.GA11712@VARK.MIT.EDU> User-Agent: Mutt/1.5.8i cc: freebsd-fs@FreeBSD.ORG cc: Mikhail Teterin cc: hackers@FreeBSD.ORG Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 11:38:48 -0000 Hi David, > Nullfs works better than unionfs. Unionfs worked well in 4.X. > Despite numerous minor bugs such as being unable to cope with > FIFOs, several people have reported using it quite successfully on > production systems. However, unionfs no longer works quite as > well in 5.X or -CURRENT. There are several reasons for this: > > 1. Nobody seems to have both the time and interest to maintain it. > > 2. Developers can't be expected to prevent regressions in > something that's unsupported. > > 3. There are a couple of people who always respond to questions > about unionfs with comments along the lines of: > ``It's broken, so we won't help you. Go away and don't tell > us if you find any bugs.'' > > There's some pretty low-hanging fruit in terms of nits to fix. > See the PR database if you're interested in helping, and don't let > anyone scare you away. ;-) > > > What about the `union' option to regular mounts? Is that safe to use? > > Last I checked, it was very broken, but I'm not sure. A little time ago, phk@ asked for people to submit regression tests for virtual filesystem like this [1]. AFAIK, nobody submitted even one test so far. This could be a good starting point to have unionfs work correctly again. However, I think FreeBSD VFS gurus should first spread some ideas and clues about tests to do. I guess indeed there are very tricky ones that most common mortals wouldn't even suspect. Regards, [1] http://lists.freebsd.org/pipermail/freebsd-current/2005-January/045743.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 11:41:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C520F16A4CE for ; Thu, 10 Mar 2005 11:41:32 +0000 (GMT) Received: from deliver.smtp.vlink.ru (alias.rigel.internal.vlink.ru [217.23.88.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FDA843D1D for ; Thu, 10 Mar 2005 11:41:32 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 358D04606B for ; Thu, 10 Mar 2005 14:41:31 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.29]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id EBA1546014 for ; Thu, 10 Mar 2005 14:41:30 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.3/8.13.3) with ESMTP id j2ABfUbx011031 for ; Thu, 10 Mar 2005 14:41:30 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.3/8.13.3/Submit) id j2ABfUEU011028; Thu, 10 Mar 2005 14:41:30 +0300 (MSK) (envelope-from dsh@vlink.ru) To: hackers@freebsd.org References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310004919.GA34206@hub.freebsd.org> From: Denis Shaposhnikov Date: Thu, 10 Mar 2005 14:41:30 +0300 In-Reply-To: <20050310004919.GA34206@hub.freebsd.org> (Kris Kennaway's message of "Thu, 10 Mar 2005 00:49:19 +0000") Message-ID: <87d5u7n2xh.fsf@neva.vlink.ru> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 11:41:32 -0000 >>>>> "Kris" == Kris Kennaway writes: Kris> nullfs seems to work fine, unionfs is very fragile and easily Kris> exploded. nullfs is absolutely useless for jail's because TOO slow. -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 11:44:12 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49F8E16A4DD for ; Thu, 10 Mar 2005 11:44:12 +0000 (GMT) Received: from eddie.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBA3743D68 for ; Thu, 10 Mar 2005 11:44:11 +0000 (GMT) (envelope-from simon@eddie.nitro.dk) Received: by eddie.nitro.dk (Postfix, from userid 1000) id 0DECC11A146; Thu, 10 Mar 2005 12:44:11 +0100 (CET) Date: Thu, 10 Mar 2005 12:44:10 +0100 From: "Simon L. Nielsen" To: Denis Shaposhnikov Message-ID: <20050310114410.GJ4908@eddie.nitro.dk> References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310004919.GA34206@hub.freebsd.org> <87d5u7n2xh.fsf@neva.vlink.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/+CTqSGWdiRg+8j" Content-Disposition: inline In-Reply-To: <87d5u7n2xh.fsf@neva.vlink.ru> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 11:44:12 -0000 --W/+CTqSGWdiRg+8j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.03.10 14:41:30 +0300, Denis Shaposhnikov wrote: > >>>>> "Kris" =3D=3D Kris Kennaway writes: >=20 > Kris> nullfs seems to work fine, unionfs is very fragile and easily > Kris> exploded. >=20 > nullfs is absolutely useless for jail's because TOO slow. That obviously depend on your use of jails and nullfs. It works just fine for me. --=20 Simon L. Nielsen --W/+CTqSGWdiRg+8j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCMDMKh9pcDSc1mlERAkXeAJ9Frkj4S6Tzxu7TdX40vriUrfOjUwCePLRy YNbuGPj/hdcZfM/27t0s5ac= =0qOy -----END PGP SIGNATURE----- --W/+CTqSGWdiRg+8j-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 11:55:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57B3116A4CE; Thu, 10 Mar 2005 11:55:57 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13C0F43D31; Thu, 10 Mar 2005 11:55:57 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id A8E362E0F6A; Thu, 10 Mar 2005 12:55:55 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 803FA407C; Thu, 10 Mar 2005 12:55:52 +0100 (CET) Date: Thu, 10 Mar 2005 12:55:52 +0100 From: Jeremie Le Hen To: "Simon L. Nielsen" Message-ID: <20050310115552.GK34822@obiwan.tataz.chchile.org> References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310004919.GA34206@hub.freebsd.org> <87d5u7n2xh.fsf@neva.vlink.ru> <20050310114410.GJ4908@eddie.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310114410.GJ4908@eddie.nitro.dk> User-Agent: Mutt/1.5.8i cc: Denis Shaposhnikov cc: hackers@freebsd.org Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 11:55:57 -0000 > That obviously depend on your use of jails and nullfs. It works just > fine for me. For me too. I mount /bin /sbin /lib /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata /usr/share in all my jails using nullfs, thus I avoid wasting storage space and an upgrade of the host also automatically updates all jails. This is IMO a very neat way do manage jails. But since my jails are neither very stressed nor time critical, I can't tell how high the speed penalty is with nullfs. I'm pretty curious about this Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 9 23:38:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BBC516A4CE; Wed, 9 Mar 2005 23:38:33 +0000 (GMT) Received: from harik.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA5943D31; Wed, 9 Mar 2005 23:38:32 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from interscan.fr.murex.com (iscan.murex.fr [172.21.17.207] (may be forged)) by harik.murex.com with ESMTP id j29NRpbW027830; Thu, 10 Mar 2005 00:27:51 +0100 (CET) Received: from mxmail.murex.com (interscan.murex.fr [127.0.0.1]) by interscan.fr.murex.com (8.11.6/8.11.6) with ESMTP id j29NlLN15139; Thu, 10 Mar 2005 00:47:24 +0100 Received: from mteterin.us.murex.com ([172.21.130.86]) by mxmail.murex.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Mar 2005 00:38:01 +0100 From: Mikhail Teterin Organization: Virtual Estates, Inc. To: hackers@FreeBSD.org Date: Wed, 9 Mar 2005 18:38:06 -0500 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503091838.06322.mi+mx@aldan.algebra.com> X-OriginalArrivalTime: 09 Mar 2005 23:38:02.0221 (UTC) FILETIME=[08C461D0:01C52501] X-Mailman-Approved-At: Thu, 10 Mar 2005 13:36:43 +0000 cc: freebsd-fs@FreeBSD.org Subject: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2005 23:38:33 -0000 Hello! The respected manual contain dire warnings, but the Google search suggests, the situation is not *that* gloomy. For example, according to http://kerneltrap.org/node/652 , nullfs was used on Bento-cluster two years ago in 2003. Is anybody working on this file-systems? Any plans, rumours? What about the `union' option to regular mounts? Is that safe to use? Thanks! -mi From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 01:29:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F7C16A4CE; Thu, 10 Mar 2005 01:28:59 +0000 (GMT) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711C643D5C; Thu, 10 Mar 2005 01:28:58 +0000 (GMT) (envelope-from ezk@fsl.cs.sunysb.edu) Received: from agora.fsl.cs.sunysb.edu (agora.fsl.cs.sunysb.edu [130.245.126.12])j2A1SQmX016359; Wed, 9 Mar 2005 20:28:26 -0500 Received: from agora.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) j2A1SP71014424; Wed, 9 Mar 2005 20:28:25 -0500 Received: (from ezk@localhost) by agora.fsl.cs.sunysb.edu (8.12.11/8.12.8/Submit) id j2A1SP4h014420; Wed, 9 Mar 2005 20:28:25 -0500 Date: Wed, 9 Mar 2005 20:28:25 -0500 Message-Id: <200503100128.j2A1SP4h014420@agora.fsl.cs.sunysb.edu> From: Erez Zadok To: Mikhail Teterin In-reply-to: Your message of "Wed, 09 Mar 2005 18:38:06 EST." <200503091838.06322.mi+mx@aldan.algebra.com> X-MailKey: Erez_Zadok X-Mailman-Approved-At: Thu, 10 Mar 2005 13:36:43 +0000 cc: freebsd-fs@freebsd.org cc: hackers@freebsd.org Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 01:29:00 -0000 At the risk of bringing up the "L" word on this forum :-), we have a fan-out unionfs implementation for Linux that doesn't explode very easily. See http://www.filesystems.org/project-unionfs.html Cheers, Erez. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 11:38:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4513616A4CE; Thu, 10 Mar 2005 11:38:33 +0000 (GMT) Received: from deliver.smtp.vlink.ru (alias.rigel.internal.vlink.ru [217.23.88.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9CAF43D54; Thu, 10 Mar 2005 11:38:31 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 78A6445CE5; Thu, 10 Mar 2005 14:38:29 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.29]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id 2CA2145C90; Thu, 10 Mar 2005 14:38:29 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.3/8.13.3) with ESMTP id j2ABcS1o010999; Thu, 10 Mar 2005 14:38:28 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.3/8.13.3/Submit) id j2ABcSZU010996; Thu, 10 Mar 2005 14:38:28 +0300 (MSK) (envelope-from dsh@vlink.ru) X-Comment-To: Kris Kennaway To: Kris Kennaway References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310004919.GA34206@hub.freebsd.org> From: Denis Shaposhnikov Date: Thu, 10 Mar 2005 14:38:28 +0300 In-Reply-To: <20050310004919.GA34206@hub.freebsd.org> (Kris Kennaway's message of "Thu, 10 Mar 2005 00:49:19 +0000") Message-ID: <87ll8vn32j.fsf@neva.vlink.ru> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 10 Mar 2005 13:36:43 +0000 cc: freebsd-fs@freebsd.org cc: Mikhail Teterin cc: hackers@freebsd.org Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 11:38:33 -0000 >>>>> "Kris" == Kris Kennaway writes: Kris> nullfs seems to work fine, unionfs is very fragile and easily Kris> exploded. nullfs is absolutely useless for jail's because TOO slow. -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 14:19:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B13E16A4EB; Thu, 10 Mar 2005 14:19:33 +0000 (GMT) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4409943D48; Thu, 10 Mar 2005 14:19:33 +0000 (GMT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas@localhost [127.0.0.1])j2AEJB2f072911; Thu, 10 Mar 2005 09:19:11 -0500 (EST) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost)j2AEJAhI072910; Thu, 10 Mar 2005 09:19:10 -0500 (EST) (envelope-from mwlucas) Date: Thu, 10 Mar 2005 09:19:10 -0500 From: "Michael W. Lucas" To: Jeremie Le Hen Message-ID: <20050310141910.GA72868@bewilderbeast.blackhelicopters.org> References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310023518.GA11712@VARK.MIT.EDU> <20050310113843.GJ34822@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310113843.GJ34822@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.1i X-Spam-Score: (0) X-Scanned-By: MIMEDefang 2.39 cc: freebsd-fs@freebsd.org cc: David Schultz cc: hackers@freebsd.org cc: Mikhail Teterin Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 14:19:36 -0000 On Thu, Mar 10, 2005 at 12:38:43PM +0100, Jeremie Le Hen wrote: > A little time ago, phk@ asked for people to submit regression tests for > virtual filesystem like this [1]. AFAIK, nobody submitted even one test > so far. This could be a good starting point to have unionfs work > correctly again. However, I think FreeBSD VFS gurus should first spread > some ideas and clues about tests to do. I guess indeed there are very > tricky ones that most common mortals wouldn't even suspect. But the mere existence of even a basic regression test would be a start and would encourage people to not hose things further. Folks, don't let the fact that you're not a guru stop you from taking a kiddie step and submitting a basic test! ==ml (who uses neither unionfs nor nullfs because of the scary man pages) -- Michael W. Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.BlackHelicopters.org/~mwlucas/ Latest book: Cisco Routers for the Desperate http://www.CiscoRoutersForTheDesperate.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 17:01:55 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B552016A4CE for ; Thu, 10 Mar 2005 17:01:55 +0000 (GMT) Received: from kuldipmanak.chamkila.org (node-40240ed2.sjc.onnet.us.uu.net [64.36.14.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA58543D5E for ; Thu, 10 Mar 2005 17:01:52 +0000 (GMT) (envelope-from aman@chamkila.org) Received: from mail.chamkila.org (localhost.localdomain [127.0.0.1]) j2AH1DBg019995; Thu, 10 Mar 2005 09:01:13 -0800 Received: from 69.36.228.194 (proxying for 192.168.96.214) (SquirrelMail authenticated user aman); by mail.chamkila.org with HTTP; Thu, 10 Mar 2005 09:01:13 -0800 (PST) Message-ID: <44497.69.36.228.194.1110474073.squirrel@69.36.228.194> In-Reply-To: <34148.69.36.228.194.1110235564.squirrel@69.36.228.194> References: <20050119103214.A27409@pooker.samsco.org> <37799.69.36.228.194.1109286815.squirrel@69.36.228.194> <421E604F.3080305@samsco.org> <34148.69.36.228.194.1110235564.squirrel@69.36.228.194> Date: Thu, 10 Mar 2005 09:01:13 -0800 (PST) From: "Amandeep Pannu" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal cc: aman@chamkila.org Subject: Re: Freebsd 5.3 problem: SCSI Errors ...Help X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:01:55 -0000 Hi all, I am encountering these SCSI errors with FreeBSD 5.3-REL-p5 Any ideas what is going on. ahd0: port 0x4000-0x40ff,0x4400-0x44ff mem 0xfc300000-0xfc301fff irq 28 at device 2.0 on pci3 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs ahd1: port 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 29 at device 2.1 on pci3 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs (probe1:ahd0:0:1:0): No or incomplete CDB sent to device. (probe1:ahd0:0:1:0): Protocol violation in Message-in phase. Attempting to abort. (probe1:ahd0:0:1:0): Abort Message Sent (probe1:ahd0:0:1:0): SCB 14 - Abort Tag Completed. found == 0x1 ahd0: Invalid Sequencer interrupt occurred. >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x23b Mode 0x0 Card was paused INTSTAT[0x0] SELOID[0x1] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x6]:(INTMASK1|INTMASK2) SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x3] KERNEL_QFREEZE_COUNT[0x3] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0x9 NEXTSCB 0xff80 qinstart = 39 qinfifonext = 40 QINFIFO: 0xe WAITING_TID_QUEUES: Pending list: 14 FIFO_USE[0x0] SCB_CONTROL[0x48]:(STATUS_RCVD|DISCENB) SCB_SCSIID[0x17] Total 1 Kernel Free SCB list: 9 15 1 2 3 4 5 6 7 8 10 11 12 13 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xf SEQIMODE[0x3f]: (ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0x9 SEQIMODE[0x3f]: (ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x8 0x0 0x0 0xf 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd0: REG0 == 0x8060, SINDEX = 0x10e, DINDEX = 0x104 ahd0: SCBPTR == 0xf, SCB_NEXT == 0xff80, SCB_NEXT2 == 0xff33 CDB 12 20 0 80 88 86 STACK: 0x236 0x2 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> ses0 at ahd0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 The system is running 5.3-REL-p5 with a custom kernel. I have also tried GENERIC with the same results. The Drives: da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) ./diskinfo -v /dev/da0s1a /dev/da0s1a 512 # sectorsize 28311552000 # mediasize in bytes (26G) 55296000 # mediasize in sectors 3442 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Thanks in advance Aman From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 17:24:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C565A16A4D0 for ; Thu, 10 Mar 2005 17:24:18 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFDFC43D48 for ; Thu, 10 Mar 2005 17:24:17 +0000 (GMT) (envelope-from loukamenov@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so364088rns for ; Thu, 10 Mar 2005 09:24:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BP4j6Rp4oVLIHfbGKy38d1d/jLa6AdgzczL+pVkueGnhZZINSMOGYHM72Bqao9Qsb1+M03qa2Q5jhl4b2eSRrIxkcxtsFZn2+1opeITHGTofJ2QO/K5XXN60+duVnIsGdg8UxCuWBnJyAanhB/Jfu82mnegiav9q5K2tgw2Wu04= Received: by 10.38.179.14 with SMTP id b14mr663794rnf; Thu, 10 Mar 2005 09:24:17 -0800 (PST) Received: by 10.38.179.75 with HTTP; Thu, 10 Mar 2005 09:24:17 -0800 (PST) Message-ID: <76f962c6050310092461fc850@mail.gmail.com> Date: Thu, 10 Mar 2005 12:24:17 -0500 From: Lou Kamenov To: "Michael W. Lucas" In-Reply-To: <20050310141910.GA72868@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310023518.GA11712@VARK.MIT.EDU> <20050310113843.GJ34822@obiwan.tataz.chchile.org> <20050310141910.GA72868@bewilderbeast.blackhelicopters.org> cc: freebsd-fs@freebsd.org cc: David Schultz cc: hackers@freebsd.org cc: Jeremie Le Hen cc: Mikhail Teterin Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lou Kamenov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:24:18 -0000 On Thu, 10 Mar 2005 09:19:10 -0500, Michael W. Lucas wrote: > On Thu, Mar 10, 2005 at 12:38:43PM +0100, Jeremie Le Hen wrote: > But the mere existence of even a basic regression test would be a > start and would encourage people to not hose things further. [..] > Folks, don't let the fact that you're not a guru stop you from taking > a kiddie step and submitting a basic test! [..] I do use unionfs on daily basis. Mostly to union $home/bin directories and such. For the last 1.5y I had it crash only 2 times. Of course trying to unmount /bin will turn into hell. I've used it successfully with pdumpfs from ports to restore old filespace view. I surely think that a stable unionfs will be a good thing (tm). Erez's unionfs has the same problem, the case there is that you wont be able to unmount it at all. (At least last time I tried with 1.0.3) Problem or not it could be easily solved with simple heuristics. Building a filespace with unioning shouldnt really be that hard. best, l From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 17:59:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8FA816A4CE; Thu, 10 Mar 2005 17:59:06 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C42943D67; Thu, 10 Mar 2005 17:59:06 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j2AHwi2T001335; Thu, 10 Mar 2005 09:58:44 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j2AHwiUX001334; Thu, 10 Mar 2005 09:58:44 -0800 Date: Thu, 10 Mar 2005 09:58:44 -0800 From: Brooks Davis To: Mikhail Teterin Message-ID: <20050310175844.GA697@odin.ac.hmc.edu> References: <200503100128.j2A1SP4h014420@agora.fsl.cs.sunysb.edu> <200503101253.20876.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <200503101253.20876.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-fs@freebsd.org cc: Erez Zadok cc: hackers@freebsd.org Subject: Re: What about inode file system? (Re: the current status of nullfs, unionfs) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:59:06 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 10, 2005 at 12:53:20PM -0500, Mikhail Teterin wrote: > A few years ago, there was a project making a filesystem, where a file's = name=20 > will simply be its inode number. It was intended to save on the name-to-i= node=20 > lookups of a regular filesystem, for applications like Squid, which keep = file=20 > names in some sort of a database already. >=20 > Does anyone know, what became of that? To the naive me it seems like this= can=20 > just be a mount option for ufs. Thanks! The inode file system was removed to ease UFS2 development. It's in the Attic under sys/ufs/ifs. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMIrTXY6L6fI4GtQRAmUFAKDZTgY8b92cdRxo57quKET/hNyzZgCfdDgC v38NNl406BDXuI4Bg3w3ZH4= =TpEj -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 18:10:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15FA616A4CF for ; Thu, 10 Mar 2005 18:10:29 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C709F43D68 for ; Thu, 10 Mar 2005 18:10:28 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 7F04315CB1 for ; Thu, 10 Mar 2005 12:09:55 -0600 (CST) Received: from 81.84.174.5 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Thu, 10 Mar 2005 12:09:55 -0600 (CST) Message-ID: <61969.81.84.174.5.1110478195.squirrel@mail.revolutionsp.com> Date: Thu, 10 Mar 2005 12:09:55 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: basic programming questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 18:10:29 -0000 Hey, Sorry if this is a little offtopic, but I need some basic help with C. I'm not a programmer, but I need to get something done in C for a project. I need to do a console application, and as I've got some free time, I'd like to add bold sentences and characters with other colors (ie blue, red, etc), to make it prettier. As my C skills go as far as declaring variables, making loops, and knowing my way around pointers, I really do not know where to start looking for the header file including these functions! I also need a function to clear the screen (in order to re-draw it). Could anyone point me to the right header files, and perhaps suggest some programs that use these functions so I can have something to start with? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 18:12:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0248F16A4CE for ; Thu, 10 Mar 2005 18:12:25 +0000 (GMT) Received: from titan.whee.org (titan.whee.org [207.195.206.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B13143D55 for ; Thu, 10 Mar 2005 18:12:24 +0000 (GMT) (envelope-from adam@whee.org) Received: from titan.whee.org (localhost [127.0.0.1]) by titan.whee.org (8.12.9/8.12.9) with ESMTP id j2AHwqqb006970; Thu, 10 Mar 2005 11:58:52 -0600 (CST) Received: from localhost (adam@localhost) by titan.whee.org (8.12.9/8.12.9/Submit) with ESMTP id j2AHwqLA006967; Thu, 10 Mar 2005 11:58:52 -0600 (CST) X-Authentication-Warning: titan.whee.org: adam owned process doing -bs Date: Thu, 10 Mar 2005 11:58:52 -0600 (CST) From: Adam Maloney X-X-Sender: adam@titan To: "H. S." In-Reply-To: <61969.81.84.174.5.1110478195.squirrel@mail.revolutionsp.com> Message-ID: References: <61969.81.84.174.5.1110478195.squirrel@mail.revolutionsp.com> X-GPG-FINGERPRINT: E39B 8D34 5F0A EA2E 4CCA 5B1D 8D55 7C25 0061 10AF X-GPG-PUBLIC_KEY: http://www.whee.org/~adam/adam-whee-org-pubkey.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: basic programming questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 18:12:25 -0000 On Thu, 10 Mar 2005, H. S. wrote: > Hey, > > Sorry if this is a little offtopic, but I need some basic help with C. > > I'm not a programmer, but I need to get something done in C for a project. > I need to do a console application, and as I've got some free time, I'd > like to add bold sentences and characters with other colors (ie blue, red, > etc), to make it prettier. > > As my C skills go as far as declaring variables, making loops, and knowing > my way around pointers, I really do not know where to start looking for > the header file including these functions! I also need a function to clear > the screen (in order to re-draw it). > > Could anyone point me to the right header files, and perhaps suggest some > programs that use these functions so I can have something to start with? curses! From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 18:25:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B00FF16A4CE for ; Thu, 10 Mar 2005 18:25:41 +0000 (GMT) Received: from internet1.mccd.edu (internet1.mccd.edu [198.189.251.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8520543D31 for ; Thu, 10 Mar 2005 18:25:41 +0000 (GMT) (envelope-from alexander.s@mccd.edu) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2005 10:27:18 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: basic programming questions Thread-Index: AcUlnPO6fHQR2fKXRVqpkIaYEJFC7gAAcVJg From: "Steven Alexander" To: "H. S." cc: freebsd-hackers@freebsd.org Subject: RE: basic programming questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 18:25:41 -0000 That's not a flame. The library is called curses, there is a version called ncurses. http://www.cs.mun.ca/~rod/ncurses/ncurses.html -Steven -----Original Message----- From: Adam Maloney [mailto:adam@whee.org]=20 Sent: Thursday, March 10, 2005 9:59 AM To: H. S. Cc: freebsd-hackers@freebsd.org Subject: Re: basic programming questions On Thu, 10 Mar 2005, H. S. wrote: > Hey, > > Sorry if this is a little offtopic, but I need some basic help with C. > > I'm not a programmer, but I need to get something done in C for a project. > I need to do a console application, and as I've got some free time, I'd > like to add bold sentences and characters with other colors (ie blue, red, > etc), to make it prettier. > > As my C skills go as far as declaring variables, making loops, and knowing > my way around pointers, I really do not know where to start looking for > the header file including these functions! I also need a function to clear > the screen (in order to re-draw it). > > Could anyone point me to the right header files, and perhaps suggest some > programs that use these functions so I can have something to start with? curses! _______________________________________________ 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" ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 18:27:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50C7916A4FE for ; Thu, 10 Mar 2005 18:27:54 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B53343D54 for ; Thu, 10 Mar 2005 18:27:54 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id B040215CB1 for ; Thu, 10 Mar 2005 12:27:15 -0600 (CST) Received: from 81.84.174.5 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Thu, 10 Mar 2005 12:27:15 -0600 (CST) Message-ID: <61985.81.84.174.5.1110479235.squirrel@mail.revolutionsp.com> In-Reply-To: References: Date: Thu, 10 Mar 2005 12:27:15 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: RE: basic programming questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 18:27:54 -0000 Thanks! I'll give it a look :-) > That's not a flame. The library is called curses, there is a version > called ncurses. > > http://www.cs.mun.ca/~rod/ncurses/ncurses.html > > -Steven > > -----Original Message----- > From: Adam Maloney [mailto:adam@whee.org] > Sent: Thursday, March 10, 2005 9:59 AM > To: H. S. > Cc: freebsd-hackers@freebsd.org > Subject: Re: basic programming questions > > > On Thu, 10 Mar 2005, H. S. wrote: > >> Hey, >> >> Sorry if this is a little offtopic, but I need some basic help with C. >> >> I'm not a programmer, but I need to get something done in C for a > project. >> I need to do a console application, and as I've got some free time, > I'd >> like to add bold sentences and characters with other colors (ie blue, > red, >> etc), to make it prettier. >> >> As my C skills go as far as declaring variables, making loops, and > knowing >> my way around pointers, I really do not know where to start looking > for >> the header file including these functions! I also need a function to > clear >> the screen (in order to re-draw it). >> >> Could anyone point me to the right header files, and perhaps suggest > some >> programs that use these functions so I can have something to start > with? > > curses! > _______________________________________________ > 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" > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > 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 Thu Mar 10 19:17:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90B0B16A4CE; Thu, 10 Mar 2005 19:17:19 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76E3F43D67; Thu, 10 Mar 2005 19:17:18 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j2AJH0mv003969; Thu, 10 Mar 2005 20:17:01 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Erez Zadok From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 10 Mar 2005 14:01:20 EST." <200503101901.j2AJ1Kgw008863@agora.fsl.cs.sunysb.edu> Date: Thu, 10 Mar 2005 20:17:00 +0100 Message-ID: <3968.1110482220@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-fs@freebsd.org cc: David Schultz cc: hackers@freebsd.org cc: Jeremie Le Hen cc: Mikhail Teterin Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 19:17:19 -0000 In message <200503101901.j2AJ1Kgw008863@agora.fsl.cs.sunysb.edu>, Erez Zadok wr ites: > Anyone can download our unionfs software and the testsuite within from > here: > > http://www.filesystems.org/project-unionfs.html > > You may consider it the first ever response to phk's request. :-) yeeeeEEEEEHAAAAA!!!!! Thankyouthankyouthankyou! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 19:20:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4220616A4CE; Thu, 10 Mar 2005 19:20:16 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 093EA43D2F; Thu, 10 Mar 2005 19:20:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id AFF007A425; Thu, 10 Mar 2005 11:20:15 -0800 (PST) Message-ID: <42309DEF.2030609@elischer.org> Date: Thu, 10 Mar 2005 11:20:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <200503100128.j2A1SP4h014420@agora.fsl.cs.sunysb.edu> <200503101253.20876.mi+mx@aldan.algebra.com> <20050310175844.GA697@odin.ac.hmc.edu> In-Reply-To: <20050310175844.GA697@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org cc: Mikhail Teterin cc: Erez Zadok cc: hackers@freebsd.org Subject: Re: What about inode file system? (Re: the current status ofnullfs, unionfs) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 19:20:16 -0000 Brooks Davis wrote: >On Thu, Mar 10, 2005 at 12:53:20PM -0500, Mikhail Teterin wrote: > > >>A few years ago, there was a project making a filesystem, where a file's name >>will simply be its inode number. It was intended to save on the name-to-inode >>lookups of a regular filesystem, for applications like Squid, which keep file >>names in some sort of a database already. >> >>Does anyone know, what became of that? To the naive me it seems like this can >>just be a mount option for ufs. Thanks! >> >> > >The inode file system was removed to ease UFS2 development. It's in the >Attic under sys/ufs/ifs. > > When it was removed it was t said that it would be easier to reimplement it again after the filesystem stuff quietenned down.. No-one has done htat, bu tit would progably be feasible to get ti foing again soon, or at least after jeff's next changes go in,.. >-- Brooks > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 20:35:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F51A16A4CE; Thu, 10 Mar 2005 20:35:00 +0000 (GMT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF51943D4C; Thu, 10 Mar 2005 20:34:59 +0000 (GMT) (envelope-from ellard@eecs.harvard.edu) Received: from localhost (localhost.eecs.harvard.edu [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 94E5B54C791; Thu, 10 Mar 2005 15:34:58 -0500 (EST) Received: from mail.eecs.harvard.edu ([127.0.0.1]) by localhost (bowser.eecs.harvard.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81391-03; Thu, 10 Mar 2005 15:34:58 -0500 (EST) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id 5D65054C7FD; Thu, 10 Mar 2005 15:34:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 58EE354C7FC; Thu, 10 Mar 2005 15:34:58 -0500 (EST) Date: Thu, 10 Mar 2005 15:34:58 -0500 (EST) From: Daniel Ellard To: Jeremie Le Hen In-Reply-To: <20050310113843.GJ34822@obiwan.tataz.chchile.org> Message-ID: <20050310153251.J73108@bowser.eecs.harvard.edu> References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310113843.GJ34822@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at eecs.harvard.edu cc: freebsd-fs@FreeBSD.ORG cc: David Schultz cc: hackers@FreeBSD.ORG cc: Mikhail Teterin Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 20:35:00 -0000 On Thu, 10 Mar 2005, Jeremie Le Hen wrote: > A little time ago, phk@ asked for people to submit regression tests for > virtual filesystem like this [1]. AFAIK, nobody submitted even one test > so far. This could be a good starting point to have unionfs work > correctly again. However, I think FreeBSD VFS gurus should first spread > some ideas and clues about tests to do. I guess indeed there are very > tricky ones that most common mortals wouldn't even suspect. I know that Kirk McKusick has a stress test he uses for his own stuff (in case you don't already know about it). -Dan From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 02:55:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 129A116A4CE for ; Fri, 11 Mar 2005 02:55:14 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id A96F143D31 for ; Fri, 11 Mar 2005 02:55:13 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so646243rnf for ; Thu, 10 Mar 2005 18:55:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=LZaM1lY1BRzut6MpV5z9sImuFedHUfC7sXiJAPHQ8Rg7K/F9XyDmOoka3gyuK/PKmOrlYWQsyE9ZoPEr72kbESE/IpD1JKn2npg4e333B+QVsNxjRfdqjK76hxC1jdSVqQ7RdaOcPaepf+XGXlMI/fR2tweuN426VxkYlJqKZ9U= Received: by 10.38.82.51 with SMTP id f51mr2513100rnb; Thu, 10 Mar 2005 18:55:13 -0800 (PST) Received: by 10.38.209.22 with HTTP; Thu, 10 Mar 2005 18:55:12 -0800 (PST) Message-ID: <84dead72050310185513e9b2b5@mail.gmail.com> Date: Fri, 11 Mar 2005 02:55:12 +0000 From: Joseph Koshy To: Amandeep Pannu In-Reply-To: <44497.69.36.228.194.1110474073.squirrel@69.36.228.194> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050119103214.A27409@pooker.samsco.org> <37799.69.36.228.194.1109286815.squirrel@69.36.228.194> <421E604F.3080305@samsco.org> <34148.69.36.228.194.1110235564.squirrel@69.36.228.194> <44497.69.36.228.194.1110474073.squirrel@69.36.228.194> cc: freebsd-hackers@freebsd.org Subject: Re: Freebsd 5.3 problem: SCSI Errors ...Help X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 02:55:14 -0000 > (probe1:ahd0:0:1:0): No or incomplete CDB sent to device. > (probe1:ahd0:0:1:0): Protocol violation in Message-in phase. > Attempting to abort. > (probe1:ahd0:0:1:0): Abort Message Sent > (probe1:ahd0:0:1:0): SCB 14 - Abort Tag Completed. > found == 0x1 > ahd0: Invalid Sequencer interrupt occurred. I've seen these kinds of symptoms when the system was overheating or had electrical problems. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 03:44:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E888416A4CE for ; Fri, 11 Mar 2005 03:44:08 +0000 (GMT) Received: from hotmail.com (bay10-f42.bay10.hotmail.com [64.4.37.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEB6543D48 for ; Fri, 11 Mar 2005 03:44:08 +0000 (GMT) (envelope-from klowd92@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Mar 2005 19:44:08 -0800 Message-ID: Received: from 24.119.116.215 by by10fd.bay10.hotmail.msn.com with HTTP; Fri, 11 Mar 2005 03:44:08 GMT X-Originating-IP: [24.119.116.215] X-Originating-Email: [klowd92@hotmail.com] X-Sender: klowd92@hotmail.com From: "klowd9 -" To: freebsd-hackers@freebsd.org Date: Fri, 11 Mar 2005 03:44:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Mar 2005 03:44:08.0793 (UTC) FILETIME=[94BE3490:01C525EC] Subject: Freebsd Asm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 03:44:09 -0000 Dear all, I am new to developing in freebsd. I was looking for any help with freebsd nasm. Any include files, defines, etc.. I already visited int80h.org and linuxassembly.org and others, And did not find any resources or include files.. If anyone can share his own files, or give any tips, would be nice. Sincerely Ben. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 05:02:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D72E916A4CE for ; Fri, 11 Mar 2005 05:02:36 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C79943D39 for ; Fri, 11 Mar 2005 05:02:36 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so666711rnf for ; Thu, 10 Mar 2005 21:02:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eggjeZoUZX0C/bpFt9CyM1+nuf3f6Xt2J0g4GojPvxnuZkBdgdO5QtWvV09t5NLt+eAdNuLfneSy1W3BPnD2G39sQC8oEolL8Y29dsOKG4lZUEb8NCadxyaZyGeHCxt6dfPlR/NYCXVnqn4TuM14PyJKbA4KJZyBw3nGoIT1fnY= Received: by 10.39.3.5 with SMTP id f5mr588720rni; Thu, 10 Mar 2005 21:02:33 -0800 (PST) Received: by 10.38.209.22 with HTTP; Thu, 10 Mar 2005 21:02:33 -0800 (PST) Message-ID: <84dead72050310210226f2ca9c@mail.gmail.com> Date: Fri, 11 Mar 2005 05:02:33 +0000 From: Joseph Koshy To: klowd9 - In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: cc: freebsd-hackers@freebsd.org Subject: Re: Freebsd Asm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 05:02:36 -0000 > I already visited int80h.org and linuxassembly.org and others, And did not > find any resources or include files.. > If anyone can share his own files, or give any tips, would be nice. It is straightforward: The assembly syntax is whatever is supported by gas(1) for your architecture. 'info gas' should be of help. The BSD make(1) infrastructure supports creating objects from assembler sources; just name your assembler files with a .S or .s suffix and include these names in your 'SRCS' make variable. Files with a ".S" suffix are preprocessed by cpp(1) before being fed into the assembler. Files with a ".s" suffix are fed into the assembler without preprocessing. See "src/share/mk/sys.mk". There are some convenient CPP macros for assembly language programmers in and . You can also study the assembly sources under "src/lib/libc/*". -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 05:02:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C663116A4CE for ; Fri, 11 Mar 2005 05:02:51 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id DF73F43D39 for ; Fri, 11 Mar 2005 05:02:50 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 36153 invoked by uid 0); 11 Mar 2005 05:01:35 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 11 Mar 2005 05:01:35 -0000 Message-ID: <423126FF.3080608@gamersimpact.com> Date: Thu, 10 Mar 2005 23:05:03 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: klowd9 - References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Freebsd Asm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 05:02:51 -0000 klowd9 - wrote: > If anyone can share his own files, or give any tips, would be nice. You aren't going to find many, if any, userland include files for assembly. The system is designed to be very portable and assembly is not. My first response, and likely that of anyone else, would be what are you doing that it needs to be done in assembly? If all you are looking for is some experience working with assembly then that's fine; there are a lot of good guides out there that teach the basics. Otherwise though if you're looking to get into developing on FreeBSD I'd recommend sticking with a higher level language. I think I remember a few guides out there on doing assembly on FreeBSD, can't remember them off the top of my head though. Honestly, coming from someone that went through that learning curve, a good ol copy of MSDOS can be a better teaching aid than doing assembly on a modern OS. I imagine almost every modern OS running on x86 will run in protected mode and therefore somewhat shield you from getting down and dirty with the processor. Using DOS will let you mess around with entering protected mode and other things. Another note, careful about using Linux guides on FreeBSD. Specifically be careful when it comes to system calls. Linux, like Windows, uses registers for passing arguments to syscalls, extras spill onto the stack, FreeBSD however passes all parameters on the stack. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 06:44:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E35116A4CE for ; Fri, 11 Mar 2005 06:44:33 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C3CF43D48 for ; Fri, 11 Mar 2005 06:44:33 +0000 (GMT) (envelope-from wbierman@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so680770rnf for ; Thu, 10 Mar 2005 22:44:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=aiE+WF5K5P9mS39HwTrvgqYzYFHxOOUDMA+n1uKki+hFfPRSAFPTFugx/hv7sxflK0DbjzFbcEi/b3lawep3GKxBBk9mAarqK95yCMJmophpeRHCnKLLepY7bPZ9z80QgPZdUrezqfVYGYxMG+S4hrnpXSyE0HRXLMO77pXbAAM= Received: by 10.38.78.51 with SMTP id a51mr882468rnb; Thu, 10 Mar 2005 22:44:32 -0800 (PST) Received: by 10.38.88.21 with HTTP; Thu, 10 Mar 2005 22:44:32 -0800 (PST) Message-ID: Date: Thu, 10 Mar 2005 20:44:32 -1000 From: William Bierman To: Joseph Koshy , freebsd-hackers@freebsd.org In-Reply-To: <84dead72050310055826fae2b3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <84dead720503092035629ea5fb@mail.gmail.com> <84dead72050310055826fae2b3@mail.gmail.com> Subject: Re: Can someone please help me? Why does init fail to start? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: William Bierman List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 06:44:33 -0000 On Thu, 10 Mar 2005 13:58:09 +0000, Joseph Koshy wrote: > > I tried with the default, but also tried just "/sbin/init" -- which I > > have verified to exist. > > > > > 3) Does 'init' run on a regular FreeBSD kernel? > > > > It's not the default kernel, but the same kernel boots on another > > machine which I setup with the install CD. > > Two things I can think of are: > > 1) The console is somehow messed up (no devfs?) so you > aren't seeing any console printfs from processes (kernel > printfs use a different [primitive] output mechanism. > Is this 5-X or 4.X? /dev was missing from my image. There ought to be some sort of output of that problem if you're in a verbose boot! Heh. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 17:53:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C81C016A4CE; Thu, 10 Mar 2005 17:53:56 +0000 (GMT) Received: from harik.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 110F843D46; Thu, 10 Mar 2005 17:53:56 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from interscan.fr.murex.com (iscan.murex.fr [172.21.17.207] (may be forged)) by harik.murex.com with ESMTP id j2AHh4bW000178; Thu, 10 Mar 2005 18:43:04 +0100 (CET) Received: from mxmail.murex.com (interscan.murex.fr [127.0.0.1]) by interscan.fr.murex.com (8.11.6/8.11.6) with ESMTP id j2AI2gd30117; Thu, 10 Mar 2005 19:02:45 +0100 Received: from mteterin.us.murex.com ([172.21.130.86]) by mxmail.murex.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Mar 2005 18:53:16 +0100 From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Erez Zadok Date: Thu, 10 Mar 2005 12:53:20 -0500 User-Agent: KMail/1.7.2 References: <200503100128.j2A1SP4h014420@agora.fsl.cs.sunysb.edu> In-Reply-To: <200503100128.j2A1SP4h014420@agora.fsl.cs.sunysb.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503101253.20876.mi+mx@aldan.algebra.com> X-OriginalArrivalTime: 10 Mar 2005 17:53:17.0015 (UTC) FILETIME=[09D62E70:01C5259A] X-Mailman-Approved-At: Fri, 11 Mar 2005 13:28:15 +0000 cc: freebsd-fs@freebsd.org cc: hackers@freebsd.org Subject: What about inode file system? (Re: the current status of nullfs, unionfs) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:53:56 -0000 A few years ago, there was a project making a filesystem, where a file's name will simply be its inode number. It was intended to save on the name-to-inode lookups of a regular filesystem, for applications like Squid, which keep file names in some sort of a database already. Does anyone know, what became of that? To the naive me it seems like this can just be a mount option for ufs. Thanks! -mi From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 18:45:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 793AD16A4CE; Thu, 10 Mar 2005 18:45:37 +0000 (GMT) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFA8E43D1F; Thu, 10 Mar 2005 18:45:36 +0000 (GMT) (envelope-from ezk@fsl.cs.sunysb.edu) Received: from agora.fsl.cs.sunysb.edu (agora.fsl.cs.sunysb.edu [130.245.126.12])j2AIj1mX018840; Thu, 10 Mar 2005 13:45:01 -0500 Received: from agora.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) j2AIj0aL008588; Thu, 10 Mar 2005 13:45:00 -0500 Received: (from ezk@localhost) by agora.fsl.cs.sunysb.edu (8.12.11/8.12.8/Submit) id j2AIj0LB008584; Thu, 10 Mar 2005 13:45:00 -0500 Date: Thu, 10 Mar 2005 13:45:00 -0500 Message-Id: <200503101845.j2AIj0LB008584@agora.fsl.cs.sunysb.edu> From: Erez Zadok To: Lou Kamenov In-reply-to: Your message of "Thu, 10 Mar 2005 12:24:17 EST." <76f962c6050310092461fc850@mail.gmail.com> X-MailKey: Erez_Zadok X-Mailman-Approved-At: Fri, 11 Mar 2005 13:28:16 +0000 cc: cwright@cs.sunysb.edu cc: Mikhail Teterin cc: freebsd-fs@freebsd.org cc: hackers@freebsd.org cc: David Schultz cc: Jeremie Le Hen Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 18:45:37 -0000 In message <76f962c6050310092461fc850@mail.gmail.com>, Lou Kamenov writes: > On Thu, 10 Mar 2005 09:19:10 -0500, Michael W. Lucas > wrote: > > On Thu, Mar 10, 2005 at 12:38:43PM +0100, Jeremie Le Hen wrote: > > But the mere existence of even a basic regression test would be a > > start and would encourage people to not hose things further. > [..] > > Folks, don't let the fact that you're not a guru stop you from taking > > a kiddie step and submitting a basic test! > [..] > > I do use unionfs on daily basis. Mostly to union $home/bin directories and > such. For the last 1.5y I had it crash only 2 times. Of course trying > to unmount /bin > will turn into hell. I've used it successfully with pdumpfs from ports > to restore > old filespace view. I surely think that a stable unionfs will be a > good thing (tm). > > Erez's unionfs has the same problem, the case there is that you wont be > able to unmount it at all. (At least last time I tried with 1.0.3) You should NEVER be allowed to unmount an underlying file system of a stackable file system, if it's busy or in use, no more than you can remove a /dev/sda drive while ffs is mounted on it. Our approach in the Linux unionfs is to prevent users from shooting themselves too much in the foot. :-) However, our unionfs does provide mechanisms such that read-only or non-busy file system branches in the union, *can* indeed be removed safely. Generally we can support arbitrary insertions and removals of branches anywhere in the (fan-out) union; however, we found out that most of our unionfs users rarely want or need that. BTW, the latest version of our linux unionfs is 1.0.9. There has been a lot of work done on our unionfs recently, and it was deemed stable enough that several LiveCD distros, including the just-released Knoppix 3.8, are using it. > Problem or not it could be easily solved with simple heuristics. > Building a filespace > with unioning shouldnt really be that hard. > > best, > l > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Erez. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 18:51:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA22516A4CE; Thu, 10 Mar 2005 18:51:50 +0000 (GMT) Received: from harik.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1240B43D3F; Thu, 10 Mar 2005 18:51:50 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from interscan.fr.murex.com (iscan.murex.fr [172.21.17.207] (may be forged)) by harik.murex.com with ESMTP id j2AIeubW003850; Thu, 10 Mar 2005 19:40:56 +0100 (CET) Received: from mxmail.murex.com (interscan.murex.fr [127.0.0.1]) by interscan.fr.murex.com (8.11.6/8.11.6) with ESMTP id j2AJ0ap01929; Thu, 10 Mar 2005 20:00:38 +0100 Received: from mteterin.us.murex.com ([172.21.130.86]) by mxmail.murex.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Mar 2005 19:51:09 +0100 From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Brooks Davis Date: Thu, 10 Mar 2005 13:51:14 -0500 User-Agent: KMail/1.7.2 References: <200503100128.j2A1SP4h014420@agora.fsl.cs.sunysb.edu> <200503101253.20876.mi+mx@aldan.algebra.com> <20050310175844.GA697@odin.ac.hmc.edu> In-Reply-To: <20050310175844.GA697@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503101351.14424.mi+mx@aldan.algebra.com> X-OriginalArrivalTime: 10 Mar 2005 18:51:10.0311 (UTC) FILETIME=[20151770:01C525A2] X-Mailman-Approved-At: Fri, 11 Mar 2005 13:28:16 +0000 cc: freebsd-fs@freebsd.org cc: Erez Zadok cc: hackers@freebsd.org Subject: Re: What about inode file system? (Re: the current status of nullfs, unionfs) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 18:51:50 -0000 > On Thu, Mar 10, 2005 at 12:53:20PM -0500, Mikhail Teterin wrote: > > A few years ago, there was a project making a filesystem, where a file's > > name will simply be its inode number. It was intended to save on the > > name-to-inode lookups of a regular filesystem, for applications like > > Squid, which keep file names in some sort of a database already. > > > > Does anyone know, what became of that? To the naive me it seems like this > > can just be a mount option for ufs. Thanks! > > The inode file system was removed to ease UFS2 development. It's in the > Attic under sys/ufs/ifs. If someone recovers it and makes it work on 5.x, I'll make a patch for Squid to take advantage of it. -mi From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 19:01:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CBE916A4CE; Thu, 10 Mar 2005 19:01:30 +0000 (GMT) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 052A943D5C; Thu, 10 Mar 2005 19:01:30 +0000 (GMT) (envelope-from ezk@fsl.cs.sunysb.edu) Received: from agora.fsl.cs.sunysb.edu (agora.fsl.cs.sunysb.edu [130.245.126.12])j2AJ1LmX019476; Thu, 10 Mar 2005 14:01:21 -0500 Received: from agora.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) j2AJ1KwD008867; Thu, 10 Mar 2005 14:01:20 -0500 Received: (from ezk@localhost) by agora.fsl.cs.sunysb.edu (8.12.11/8.12.8/Submit) id j2AJ1Kgw008863; Thu, 10 Mar 2005 14:01:20 -0500 Date: Thu, 10 Mar 2005 14:01:20 -0500 Message-Id: <200503101901.j2AJ1Kgw008863@agora.fsl.cs.sunysb.edu> From: Erez Zadok To: Jeremie Le Hen In-reply-to: Your message of "Thu, 10 Mar 2005 12:38:43 +0100." <20050310113843.GJ34822@obiwan.tataz.chchile.org> X-MailKey: Erez_Zadok X-Mailman-Approved-At: Fri, 11 Mar 2005 13:28:16 +0000 cc: freebsd-fs@freebsd.org cc: David Schultz cc: hackers@freebsd.org cc: Mikhail Teterin Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 19:01:30 -0000 In message <20050310113843.GJ34822@obiwan.tataz.chchile.org>, Jeremie Le Hen writes: > A little time ago, phk@ asked for people to submit regression tests for > virtual filesystem like this [1]. AFAIK, nobody submitted even one test > so far. This could be a good starting point to have unionfs work > correctly again. However, I think FreeBSD VFS gurus should first spread > some ideas and clues about tests to do. I guess indeed there are very > tricky ones that most common mortals wouldn't even suspect. I fully agree that a regression suite is needed. Since my group develops a lot of file systems, we have been doing two new things in the past year: 1. We've extracted a subset of the VSX-PCTS posix test suite that just deals with file systems related system calls, and made some changes to it to make it easier to test an arbitrary file system (the package had all sorts of hard-coded assumptions). We've been running it for more than 2 months now and caught dozens of bugs in our file systems, which we're fixing nowadays. Note: in the past, we've used postmark, fsx, bonnie, large compiles, and more as ways of testing file systems' stability; but the posix test suite was able to catch lots of corner cases more directly that none of these other packages could. I fully intend to make this re-packaged VSX-PCTS tool available publicly. And I wholeheartedly recommend it to anyone who develops or maintains file systems. 2. Unionfs has different semantics than regular file systems. As Charles said in his email, unionfs *seems* easy conceptually (we thought so too), but the devil is in the details. It's much harder in practice to deal with all of the unusual border cases and semantic ambiguities that unioning introduces. So, we've begun building a unionfs-specific regression test suite, which we continue to enhance and release together with our unionfs sources. Examples of tests we try is mixes of readonly and write branches, forcing conditions that will result in copy-ups and whiteouts, etc. Although our test suite is specific to our linux implementation, conceptually both the bsd and linux unionfs's are the same, and so the test suite we have could be easily adapted to suite freebsd's needs. Anyone can download our unionfs software and the testsuite within from here: http://www.filesystems.org/project-unionfs.html You may consider it the first ever response to phk's request. :-) Cheers, Erez. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 10 23:31:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0051C16A4CE; Thu, 10 Mar 2005 23:31:13 +0000 (GMT) Received: from harik.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 697BD43D1F; Thu, 10 Mar 2005 23:31:12 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from interscan.fr.murex.com (iscan.murex.fr [172.21.17.207] (may be forged)) by harik.murex.com with ESMTP id j2ANKTbW018025; Fri, 11 Mar 2005 00:20:29 +0100 (CET) Received: from mxmail.murex.com (interscan.murex.fr [127.0.0.1]) by interscan.fr.murex.com (8.11.6/8.11.6) with ESMTP id j2ANeD518554; Fri, 11 Mar 2005 00:40:13 +0100 Received: from mteterin.us.murex.com ([172.21.130.86]) by mxmail.murex.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Mar 2005 00:30:45 +0100 From: Mikhail Teterin Organization: Virtual Estates, Inc. To: David Schultz Date: Thu, 10 Mar 2005 18:30:48 -0500 User-Agent: KMail/1.7.2 References: <200503091838.06322.mi+mx@aldan.algebra.com> <20050310023518.GA11712@VARK.MIT.EDU> In-Reply-To: <20050310023518.GA11712@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503101830.49047.mi+mx@aldan.algebra.com> X-OriginalArrivalTime: 10 Mar 2005 23:30:45.0429 (UTC) FILETIME=[2ED4F650:01C525C9] X-Mailman-Approved-At: Fri, 11 Mar 2005 13:28:16 +0000 cc: freebsd-fs@freebsd.org cc: hackers@freebsd.org Subject: Re: the current status of nullfs, unionfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 23:31:13 -0000 > Nullfs works better than unionfs. Unionfs worked well in 4.X. > > What about the `union' option to regular mounts? Is that safe to use? [...] > Last I checked, it [mount -ounion -mi] was very broken, but I'm not sure. BTW, how is unionfs different from nullfs with the union option? mount -t nullfs -ounion /a /b vs. mount -t unionfs /a /b ? Thanks! -mi From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 14:56:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95D3716A4CE; Fri, 11 Mar 2005 14:56:35 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4FDE43D5F; Fri, 11 Mar 2005 14:56:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j2BEuXg6052135; Fri, 11 Mar 2005 08:56:33 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <4231B19D.8060406@centtech.com> Date: Fri, 11 Mar 2005 08:56:29 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/761/Thu Mar 10 15:01:48 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 14:56:35 -0000 Speaking of filesytems :), I have a real need for a global filesystem (or shared fs, or clustered fs, or whatever), and my favorite OS doesn't have one (that I know of!). I saw that a few years back a few people were working on getting GFS working on FreeBSD, but there's no recent mention of that. Is anyone working on this, or would someone like to work on it? I am not much of a code guru, but I have the resources to test this technology under all types of loads, and we are currently using a commercial software to handle my needs (polyserve - which they have flat out told me 'no' for FreeBSD support), but I would much prefer to be on FreeBSD. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 15:15:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8945916A4CE; Fri, 11 Mar 2005 15:15:43 +0000 (GMT) Received: from titan.whee.org (titan.whee.org [207.195.206.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1635A43D2D; Fri, 11 Mar 2005 15:15:43 +0000 (GMT) (envelope-from adam@whee.org) Received: from titan.whee.org (localhost [127.0.0.1]) by titan.whee.org (8.12.9/8.12.9) with ESMTP id j2BF27qb018604; Fri, 11 Mar 2005 09:02:07 -0600 (CST) Received: from localhost (adam@localhost) by titan.whee.org (8.12.9/8.12.9/Submit) with ESMTP id j2BF2696018601; Fri, 11 Mar 2005 09:02:06 -0600 (CST) X-Authentication-Warning: titan.whee.org: adam owned process doing -bs Date: Fri, 11 Mar 2005 09:02:06 -0600 (CST) From: Adam Maloney X-X-Sender: adam@titan To: Eric Anderson In-Reply-To: <4231B19D.8060406@centtech.com> Message-ID: References: <4231B19D.8060406@centtech.com> X-GPG-FINGERPRINT: E39B 8D34 5F0A EA2E 4CCA 5B1D 8D55 7C25 0061 10AF X-GPG-PUBLIC_KEY: http://www.whee.org/~adam/adam-whee-org-pubkey.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-fs@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:15:43 -0000 On Fri, 11 Mar 2005, Eric Anderson wrote: > Speaking of filesytems :), I have a real need for a global filesystem (or "me too" I played with CODA a few months ago but it didn't seem to be solid, and didn't fit my needs. Everything else I've looked at is Linux-only. Please follow-up to the list, I'd be very interested in seeing what other projects are available. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 15:23:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5342416A4CE; Fri, 11 Mar 2005 15:23:19 +0000 (GMT) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED8D343D46; Fri, 11 Mar 2005 15:23:18 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 5C124118CC; Fri, 11 Mar 2005 16:27:50 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52734-07; Fri, 11 Mar 2005 16:27:41 +0100 (CET) Received: from [192.168.20.107] (ALagny-109-1-7-69.w81-50.abo.wanadoo.fr [81.50.48.69]) by smtp.xbsd.org (Postfix) with ESMTP id 8C81C118B8; Fri, 11 Mar 2005 16:27:40 +0100 (CET) Message-ID: <4231B7D5.3070306@xbsd.org> Date: Fri, 11 Mar 2005 16:23:01 +0100 From: Florent Thoumie User-Agent: Mozilla Thunderbird 1.0 (X11/20050107) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Maloney References: <4231B19D.8060406@centtech.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0EF28DF9D4686C8E7272200C" X-Virus-Scanned: amavisd-new at xbsd.org cc: freebsd-fs@freebsd.org cc: freebsd-hackers@freebsd.org cc: Eric Anderson Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:23:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0EF28DF9D4686C8E7272200C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adam Maloney wrote: > On Fri, 11 Mar 2005, Eric Anderson wrote: > >> Speaking of filesytems :), I have a real need for a global filesystem >> (or > > > "me too" > > I played with CODA a few months ago but it didn't seem to be solid, and > didn't fit my needs. Everything else I've looked at is Linux-only. > Please follow-up to the list, I'd be very interested in seeing what > other projects are available. > _______________________________________________ > 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 don't know if DRBD [1] is a good implementation (Linux only), but it works flawlessly, replication is fast (i got ~35MB/s) and it's quite simple to get it working. ENBD [2] isn't based on the same concept, it "exports" block devices through network via userland application, though it needs a kernel module for client side. I'd like something like DRBD exists for FreeBSD but I'm not aware of such an implementation. [1] http://www.drbd.org/ [2] http://www.it.uc3m.es/~ptb/nbd/ -- flz --------------enig0EF28DF9D4686C8E7272200C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMbfZMxEkbVFH3PQRAgy4AJ92kdkJSTVpxMkajNLZq2sDUXqKjACfdOAJ e8MsjidFFmILVDsLOjWRZD8= =qesT -----END PGP SIGNATURE----- --------------enig0EF28DF9D4686C8E7272200C-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 15:29:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CB9916A4CF; Fri, 11 Mar 2005 15:29:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E060D43D31; Fri, 11 Mar 2005 15:29:51 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j2BFTpe1090368; Fri, 11 Mar 2005 15:29:51 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j2BFTpBC090367; Fri, 11 Mar 2005 15:29:51 GMT (envelope-from csjp) Date: Fri, 11 Mar 2005 15:29:51 +0000 From: "Christian S.J. Peron" To: freebsd-security@freebsd.org Message-ID: <20050311152951.GA90290@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: FreeBSD trusted execution system: beta testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:29:52 -0000 All, I have written a trusted execution module and would appreciate if anyone could help in testing. This module provides a functionality similar to NetBSD's verified exec mechanism. Once the design details of this security policy has been solidified, I will be releasing a white paper which describes the technical implementation in greater detail. The mac_chkexec policy logic can be found here: http://people.freebsd.org/~csjp/mac/trustedexec.png Q: What is mac_chkexec? A: It's a mandatory access control policy which ensures that if the code contained in a binary, shell script, shared object or kernel module has been modified from it's "trusted" form, it can not be executed. It also ensures that untrusted code can not be executed. I.E. If an adversary uploads an agent or rogue program, it should not be executed. In addition, dependencies are supported. Since configuration files, system databases or other files can alter how a program runs, it is possible to make the policy verify the integrity of these dependencies before allowing the execution of the object. Q: What is required to run mac_chkexec? A: This policy requires that options MAC be compiled into your kernel. Since it depends on extended attributes for dependency and checksum storage, it also requires UFS2. This security policy requires FreeBSD 5.X Q: How do I set this up and test it? A: cd /usr/src/sys fetch http://people.freebsd.org/~csjp/mac/mac_vnode_mmap.1106783302.diff patch < mac_vnode_mmap.1106783302.diff NOTE: Patch should work against -CURRENT or RELENG_5 Add the following line to your kernel config: options MAC Now Recompile and install your kernel. Download, build and install the mac_chkexec kernel module: fetch http://people.freebsd.org/~csjp/mac/mac_chkexec.1110510616.tar.gz tar zxvf mac_chkexec.1110510616.tar.gz cd mac_chkexec make make install The policy can be loaded using: kldload mac_chkexec Download, build and install the set{get}fhash user-space utility: cd /usr/src/usr.sbin fetch http://people.freebsd.org/~csjp/mac/getfhash.1110501625.shar sh getfhash.1110501625.shar cd getfhash make make install ln -s /usr/sbin/getfhash /usr/sbin/setfhash Q: I have everything installed, how do I generate my baseline? A: Easy, load the module and run your system like you would any other day. By default when you load the module without "enforcing" the policy, the trusted exec system is in "learning" mode. Which means anytime an object gets executed, a checksum is computed and stored with the object. If you do not want to wait for nature to take it course, you can always force the calculation and storage of checksums using setfhash. setfhash /bin/ls Q: How can I see what checksum is currently registered for an object? A: getfhash /bin/ls Q: How can I set dependencies for an object? A: setfhash -m /etc/rc.firewall /bin/ipfw Executables can have more then one dependency. You can use a colon to separate them: setfhash -m /path/foo:/path/foo/test /bin/ls NOTE: DEPENDENCIES PATHNAMES ARE RELATIVE TO THE CALLING PROCESS WITH COMPLICATES THINGS IS CHROOT OR JAIL ENVIRONMENTS. Q: OK, I've generated my baseline, now how do I start enforcing the policy? A: sysctl security.mac.chkexec.enforce=1 NOTE: If you plan on doing a buildworld, you might want to increase the cache size to something like 1024 sysctl security.mac.chkexec.cache.objmax=1024 Good luck & Thanks! -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 15:40:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA37416A4CE; Fri, 11 Mar 2005 15:40:13 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ACC743D58; Fri, 11 Mar 2005 15:40:13 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j2BFdse9025970; Fri, 11 Mar 2005 09:39:54 -0600 (CST) (envelope-from dan) Date: Fri, 11 Mar 2005 09:39:54 -0600 From: Dan Nelson To: Florent Thoumie Message-ID: <20050311153954.GC92140@dan.emsphone.com> References: <4231B19D.8060406@centtech.com> <4231B7D5.3070306@xbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4231B7D5.3070306@xbsd.org> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-fs@freebsd.org cc: Eric Anderson cc: freebsd-hackers@freebsd.org Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:40:13 -0000 In the last episode (Mar 11), Florent Thoumie said: > Adam Maloney wrote: > >On Fri, 11 Mar 2005, Eric Anderson wrote: > >>Speaking of filesytems :), I have a real need for a global filesystem > >>(or > > > >"me too" > > I don't know if DRBD [1] is a good implementation (Linux only), > but it works flawlessly, replication is fast (i got ~35MB/s) > and it's quite simple to get it working. > > ENBD [2] isn't based on the same concept, it "exports" block > devices through network via userland application, though it > needs a kernel module for client side. > > I'd like something like DRBD exists for FreeBSD but I'm not aware of > such an implementation. You want geom_gate. See the ggatec, ggated, and ggatel manpages. Note that none of the packages mentioned so far will give you a cluster filesystem; they are just a cheaper way of sharing block devices than a Fibre Channel SAN. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 15:41:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D51916A4CE; Fri, 11 Mar 2005 15:41:10 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC1F43D1D; Fri, 11 Mar 2005 15:41:09 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j2BFf93h052589; Fri, 11 Mar 2005 09:41:09 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <4231BC11.7030604@centtech.com> Date: Fri, 11 Mar 2005 09:41:05 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Thoumie References: <4231B19D.8060406@centtech.com> <4231B7D5.3070306@xbsd.org> In-Reply-To: <4231B7D5.3070306@xbsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/761/Thu Mar 10 15:01:48 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-fs@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:41:10 -0000 Florent Thoumie wrote: > Adam Maloney wrote: > >> On Fri, 11 Mar 2005, Eric Anderson wrote: >> >>> Speaking of filesytems :), I have a real need for a global filesystem >>> (or >> >> >> >> "me too" >> >> I played with CODA a few months ago but it didn't seem to be solid, and >> didn't fit my needs. Everything else I've looked at is Linux-only. >> Please follow-up to the list, I'd be very interested in seeing what >> other projects are available. >> _______________________________________________ >> 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 don't know if DRBD [1] is a good implementation (Linux only), but it > works flawlessly, replication is fast (i got ~35MB/s) and it's quite > simple to get it working. > > ENBD [2] isn't based on the same concept, it "exports" block devices > through network via userland application, though it needs a kernel > module for client side. > > I'd like something like DRBD exists for FreeBSD but I'm not aware of > such an implementation. > > [1] http://www.drbd.org/ > [2] http://www.it.uc3m.es/~ptb/nbd/ GEOM Gate does a part of this. I thing using vinum+geom gate you could get a similar setup. However, this isn't exactly what I want - I don't need a 'mirror', I need a cluster of active machines serving the same disk data. For what it's worth, there is an nbd port: net/nbd-server Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 15:45:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E13F16A4CE; Fri, 11 Mar 2005 15:45:42 +0000 (GMT) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 924F643D39; Fri, 11 Mar 2005 15:45:41 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id EBFFB118C9; Fri, 11 Mar 2005 16:50:12 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53038-04; Fri, 11 Mar 2005 16:50:04 +0100 (CET) Received: from [192.168.20.107] (ALagny-109-1-7-69.w81-50.abo.wanadoo.fr [81.50.48.69]) by smtp.xbsd.org (Postfix) with ESMTP id 2D71211701; Fri, 11 Mar 2005 16:50:02 +0100 (CET) Message-ID: <4231BD14.3080506@xbsd.org> Date: Fri, 11 Mar 2005 16:45:24 +0100 From: Florent Thoumie User-Agent: Mozilla Thunderbird 1.0 (X11/20050107) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <4231B19D.8060406@centtech.com> <4231B7D5.3070306@xbsd.org> <4231BC11.7030604@centtech.com> In-Reply-To: <4231BC11.7030604@centtech.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB0C0EF517BD0A6FC0EC57F41" X-Virus-Scanned: amavisd-new at xbsd.org cc: freebsd-fs@freebsd.org cc: freebsd-hackers@freebsd.org cc: Dan Nelson Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:45:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB0C0EF517BD0A6FC0EC57F41 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Anderson wrote: > Florent Thoumie wrote: >> I don't know if DRBD [1] is a good implementation (Linux only), >> but it >> works flawlessly, replication is fast (i got ~35MB/s) and it's quite >> simple to get it working. >> >> ENBD [2] isn't based on the same concept, it "exports" block devices >> through network via userland application, though it needs a kernel >> module for client side. >> >> I'd like something like DRBD exists for FreeBSD but I'm not aware of >> such an implementation. >> >> [1] http://www.drbd.org/ >> [2] http://www.it.uc3m.es/~ptb/nbd/ > > > GEOM Gate does a part of this. I thing using vinum+geom gate you could > get a similar setup. > However, this isn't exactly what I want - I don't need a 'mirror', I > need a cluster of active machines serving the same disk data. Ok, good to know, thanks for pointing this. > For what it's worth, there is an nbd port: > net/nbd-server I think that's not really the good thing to do, and FreeBSD doesn't have support for nbd-client, so I may just forget it :) -- flz --------------enigB0C0EF517BD0A6FC0EC57F41 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMb0YMxEkbVFH3PQRAoczAJ9S95VTX3riUxcad+5317RBHZYGTQCfT4E5 /Zcsxt085QphQgy1JpPPw94= =wYRE -----END PGP SIGNATURE----- --------------enigB0C0EF517BD0A6FC0EC57F41-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 18:06:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5938016A4CE for ; Fri, 11 Mar 2005 18:06:33 +0000 (GMT) Received: from smtp.poczta.interia.pl (smtp1.poczta.interia.pl [217.74.65.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8866743D49 for ; Fri, 11 Mar 2005 18:06:32 +0000 (GMT) (envelope-from grze.ch@poczta.fm) Received: by smtp.poczta.interia.pl (INTERIA.PL, from userid 502) id E8FCDD0417; Fri, 11 Mar 2005 19:06:30 +0100 (CET) Received: from poczta.interia.pl (mi04.poczta.interia.pl [10.217.12.4]) by smtp.poczta.interia.pl (INTERIA.PL) with ESMTP id 7FA80D0E39 for ; Fri, 11 Mar 2005 19:06:30 +0100 (CET) Received: by poczta.interia.pl (INTERIA.PL, from userid 502) id 4BEF336B6D; Fri, 11 Mar 2005 19:06:29 +0100 (CET) Received: from [192.168.0.2] (unknown [83.238.166.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by poczta.interia.pl (INTERIA.PL) with ESMTP id 2423936B6A for ; Fri, 11 Mar 2005 19:06:28 +0100 (CET) Message-ID: <4231DE2D.9080505@poczta.fm> Date: Fri, 11 Mar 2005 19:06:37 +0100 From: Grzesiek User-Agent: Mozilla Thunderbird 1.0 (FreeBSD i686/20041206) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-EMID: e7753138 Subject: kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: grze.ch@poczta.fm List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 18:06:33 -0000 I have a problem with my kernel. FreeBSD bsd.elesem.net 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #4: Mon Mar 7 22:23:10 CET 2005 user@proxy.elesem.net:/home/tmp/usr/obj/usr/src/sys/CORE-Rev.5.3-R_bsd i386 #0 doadump () at pcpu.h:159 #1 0xc04d11d8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc04d1456 in panic (fmt=0xc0657558 "Duplicate free of item %p from zone %p(%s)\n") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc05f0d6c in uma_dbg_free (zone=0xc0c44ae0, slab=0xc0f08fa8, item=0xc0f08600) at /usr/src/sys/vm/uma_dbg.c:299 #4 0xc05efb3b in uma_zfree_arg (zone=0xc0c44ae0, item=0xc0f08600, udata=0x0) at /usr/src/sys/vm/uma_core.c:2237 #5 0xc0500542 in m_freem (mb=0x0) at uma.h:302 #6 0xc0438369 in fr_check (ip=0xc0f08634, hlen=20, ifp=0xc0fb9414, out=0, mp=0xc67d1c8c) at /usr/src/sys/contrib/ipfilter/netinet/fil.c:1401 #7 0xc04396aa in fr_check_wrapper (arg=0x0, mp=0x0, ifp=0xc0fb9414, dir=1, inp=0x0) at /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:343 #8 0xc053782d in pfil_run_hooks (ph=0xc069dc40, mp=0xc67d1cd4, ifp=0xc0fb9414, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:137 #9 0xc0566c17 in ip_input (m=0xc0f08600) at /usr/src/sys/netinet/ip_input.c:439 #10 0xc053629a in netisr_processqueue (ni=0xc069b058) at /usr/src/sys/net/netisr.c:233 #11 0xc0536482 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346 #12 0xc04bfd88 in ithread_loop (arg=0xc0e24480) at /usr/src/sys/kern/kern_intr.c:547 #13 0xc04bf214 in fork_exit (callout=0xc04bfc64 , arg=0xc0e24480, frame=0xc67d1d48) at /usr/src/sys/kern/kern_fork.c:811 #14 0xc060eaac in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 Please help me. ---------------------------------------------------------------------- Najlepsze MOTO w sieci! >>> http://link.interia.pl/f1862 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 19:56:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C30B016A4CE for ; Fri, 11 Mar 2005 19:56:37 +0000 (GMT) Received: from demon.noconname.org (19.Red-80-26-109.pooles.rima-tde.net [80.26.109.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8603743D1F for ; Fri, 11 Mar 2005 19:56:36 +0000 (GMT) (envelope-from jncastellano@noconname.org) Received: from [192.168.0.11] (unknown [192.168.0.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by demon.noconname.org (Postfix) with ESMTP id 3BADD35F1 for ; Fri, 11 Mar 2005 19:53:22 +0100 (CET) Message-ID: <4231F7E8.7070603@noconname.org> Date: Fri, 11 Mar 2005 20:56:24 +0100 From: =?ISO-8859-1?Q?Jos=E9_Nicol=E1s_Castellano?= Organization: No cON Name User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Content-Type: multipart/mixed; boundary="------------020104020608080907080300" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: List of Maj-Min Devices X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jncastellano@noconname.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 19:56:37 -0000 This is a multi-part message in MIME format. --------------020104020608080907080300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi!, I'm making mknod to some devices in new system like /dev/ttyp0 and so and i can't found a list of maj and min numbers. Where can i found it? Thanks -- Jose Nicolas Castellano Presidente - Asociación No cON Name Tel: +34 616 727 675 E-Mail : jncastellano@noconname.org WWW: www.noconname.org --------------020104020608080907080300-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 20:05:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 9F9CB16A4CF; Fri, 11 Mar 2005 20:05:22 +0000 (GMT) Date: Fri, 11 Mar 2005 20:05:22 +0000 From: Kris Kennaway To: Jos? Nicol?s Castellano Message-ID: <20050311200522.GJ72527@hub.freebsd.org> References: <4231F7E8.7070603@noconname.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4231F7E8.7070603@noconname.org> User-Agent: Mutt/1.4.2.1i cc: "freebsd-hackers@freebsd.org" Subject: Re: List of Maj-Min Devices X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 20:05:22 -0000 On Fri, Mar 11, 2005 at 08:56:24PM +0100, Jos? Nicol?s Castellano wrote: > Hi!, > > I'm making mknod to some devices in new system like /dev/ttyp0 and so > and i can't found a list of maj and min numbers. > Where can i found it? On 4.x and older, the /dev/MAKEDEV script. On 5.x and newer, devfs does this for you. Kris From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 20:55:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B86E616A4CE for ; Fri, 11 Mar 2005 20:55:40 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D32543D2F for ; Fri, 11 Mar 2005 20:55:40 +0000 (GMT) (envelope-from aaron.glenn@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so918737rng for ; Fri, 11 Mar 2005 12:55:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Eo+2Q8LHbSEKhR8ypnSGqZZi5pDX2Ya5ifv7yPw3KTjY2P4ubCzxV27DzkbEvvthx2lZwh42QyisUZdI/cThzrJR360MMeUhWFNjllJzhiJybwtlUhi+1qiVmf43NQ/9CAJiZofoCCbf/nKHuz4l8XD7n9KXVn0kvVF7nfzta+8= Received: by 10.38.81.38 with SMTP id e38mr3046337rnb; Fri, 11 Mar 2005 12:55:39 -0800 (PST) Received: by 10.38.151.77 with HTTP; Fri, 11 Mar 2005 12:55:39 -0800 (PST) Message-ID: <18f6019405031112553b7286d2@mail.gmail.com> Date: Fri, 11 Mar 2005 12:55:39 -0800 From: Aaron Glenn To: Eric Anderson In-Reply-To: <4231B19D.8060406@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4231B19D.8060406@centtech.com> cc: freebsd-fs@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Glenn List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 20:55:40 -0000 On Fri, 11 Mar 2005 08:56:29 -0600, Eric Anderson wrote: > Is anyone working on this, or would someone like to work on it? I am not much of a code guru, but I have the resources to test this technology under all types of loads, and we are currently using a commercial software to handle my needs (polyserve - which they have flat out told me 'no' for FreeBSD support), but I would much prefer to be on FreeBSD. This has been a persistant itch for as long as I can remember (4.3) but no one with the required skills has attempted to scratch it....yet aaron.glenn From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 22:20:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4707416A4CE for ; Fri, 11 Mar 2005 22:20:00 +0000 (GMT) Received: from mx2.netflix.com (mail2.netflix.com [216.35.131.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 092F743D31 for ; Fri, 11 Mar 2005 22:20:00 +0000 (GMT) (envelope-from nsayer@kfu.com) Received: from [172.22.8.180] ([172.22.8.180]) by mx2.netflix.com (8.12.8/8.12.8) with ESMTP id j2BMJxKD004550 for ; Fri, 11 Mar 2005 14:19:59 -0800 Message-ID: <4232198F.5030705@kfu.com> Date: Fri, 11 Mar 2005 14:19:59 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------000809040101070005010705" Subject: 6to4, stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 22:20:00 -0000 This is a multi-part message in MIME format. --------------000809040101070005010705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (I sent a version of this e-mail earlier today without the patch, but my return address was not the same as the subscribed one, so I think it got ate. Appologies if this is a dupe) Historically, I've used FreeBSD machines as NAT routers. Call me a traitor if you must, but it's getting harder to justify not simply putting one of those little Linksys/Netgear/SMC/whatever NAT routers in place and having the FreeBSD machine be a server behind the box instead. One of the last considerations remaining is IPv6. Most boxes now have the concept of a "DMZ" host. They will, aparently, perform simple address substitution on the IP header for packets that arrive of an unknown protocol and send them to the DMZ host (living on the inside LAN - thus calling it a DMZ host is a bit of a misnomer, but that's a semantic debate for another occasion). This would be ideal for 6to4 - incoming packets would simply arrive and be processed. The trouble appears to be the outgoing side. The machine's actual IPv4 address is not the same as the *outside* IPv4 address, so one of two things is happening (I'm not sure which): Either the blanket prohibition on RFC-1918 addresses having anything to do with 6to4 is getting in the way, or stf0 having a "foreign" prefix (that is, a prefix that does not relate to a physical interface on the machine) is confusing it. I've come up with the attached patch. It simply allows you to optionally neuter the RFC-1918 checks. The problem is that there are some instances where those checks would still be good to have - specifically, in the code that checks IPv6 prefixes of incoming packets. There's no reason to allow RFC-1918 addresses to appear there. But being able to be selective would mean having to do a bit more rearchitecture than I feel like, at least today. :-) --------------000809040101070005010705 Content-Type: text/plain; name="stf_rfc1918_patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="stf_rfc1918_patch.txt" --- net/if_stf.c.orig Thu Jul 15 01:26:06 2004 +++ net/if_stf.c Fri Mar 11 11:54:23 2005 @@ -89,6 +89,7 @@ #include #include #include +#include #include #include @@ -183,6 +184,13 @@ struct if_clone stf_cloner = IFC_CLONE_INITIALIZER(STFNAME, NULL, 0, NULL, stf_clone_match, stf_clone_create, stf_clone_destroy); +SYSCTL_DECL(_net_link); +SYSCTL_NODE(_net_link, IFT_STF, stf, CTLFLAG_RW, 0, "6to4 Interface"); + +static int no_rfc1918check = 0; +SYSCTL_INT(_net_link_stf, OID_AUTO, permit_rfc1918, CTLFLAG_RW, + &no_rfc1918check, 0, "permit RFC-1918 addresses"); + static int stf_clone_match(struct if_clone *ifc, const char *name) { @@ -567,6 +575,9 @@ isrfc1918addr(in) struct in_addr *in; { + if (no_rfc1918check) + return 0; + /* * returns 1 if private address range: * 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 --------------000809040101070005010705-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 23:07:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A09A516A4CE for ; Fri, 11 Mar 2005 23:07:22 +0000 (GMT) Received: from mx2.netflix.com (mail2.netflix.com [216.35.131.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ED9243D48 for ; Fri, 11 Mar 2005 23:07:22 +0000 (GMT) (envelope-from nsayer@kfu.com) Received: from [172.22.8.180] ([172.22.8.180]) by mx2.netflix.com (8.12.8/8.12.8) with ESMTP id j2BN7LKD014861 for ; Fri, 11 Mar 2005 15:07:22 -0800 Message-ID: <423224A9.9010109@kfu.com> Date: Fri, 11 Mar 2005 15:07:21 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4232198F.5030705@kfu.com> In-Reply-To: <4232198F.5030705@kfu.com> Content-Type: multipart/mixed; boundary="------------030102080108030906020300" Subject: Re: 6to4, stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 23:07:22 -0000 This is a multi-part message in MIME format. --------------030102080108030906020300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Turns out there is also a check in stf_output that I need to neuter for this configuration. Attached is a revised patch. --------------030102080108030906020300 Content-Type: text/plain; name="stf_rfc1918_patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="stf_rfc1918_patch.txt" --- net/if_stf.c.orig Thu Jul 15 01:26:06 2004 +++ net/if_stf.c Fri Mar 11 15:05:52 2005 @@ -89,6 +89,7 @@ #include #include #include +#include #include #include @@ -183,6 +184,13 @@ struct if_clone stf_cloner = IFC_CLONE_INITIALIZER(STFNAME, NULL, 0, NULL, stf_clone_match, stf_clone_create, stf_clone_destroy); +SYSCTL_DECL(_net_link); +SYSCTL_NODE(_net_link, IFT_STF, stf, CTLFLAG_RW, 0, "6to4 Interface"); + +static int no_rfc1918check = 0; +SYSCTL_INT(_net_link_stf, OID_AUTO, permit_rfc1918, CTLFLAG_RW, + &no_rfc1918check, 0, "permit RFC-1918 addresses"); + static int stf_clone_match(struct if_clone *ifc, const char *name) { @@ -455,11 +463,13 @@ * we shouldn't generate output. Without this check, we'll end up * using wrong IPv4 source. */ - ia6 = stf_getsrcifa6(ifp); - if (ia6 == NULL) { - m_freem(m); - ifp->if_oerrors++; - return ENETDOWN; + if (!no_rfc1918check) { + ia6 = stf_getsrcifa6(ifp); + if (ia6 == NULL) { + m_freem(m); + ifp->if_oerrors++; + return ENETDOWN; + } } if (m->m_len < sizeof(*ip6)) { @@ -567,6 +577,9 @@ isrfc1918addr(in) struct in_addr *in; { + if (no_rfc1918check) + return 0; + /* * returns 1 if private address range: * 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 --------------030102080108030906020300-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 23:19:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A529116A4CE for ; Fri, 11 Mar 2005 23:19:52 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B6243D4C for ; Fri, 11 Mar 2005 23:19:51 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)j2BNJffD089705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2005 08:19:42 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 12 Mar 2005 08:19:41 +0900 Message-ID: From: Hajimu UMEMOTO To: Nick Sayer In-Reply-To: <4232198F.5030705@kfu.com> References: <4232198F.5030705@kfu.com> User-Agent: xcite1.38> Wanderlust/2.13.3 (You Oughta Know) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-PRERELEASE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b2 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 12 Mar 2005 08:19:42 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on cheer.mahoroba.org cc: freebsd-hackers@freebsd.org Subject: Re: 6to4, stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 23:19:52 -0000 Hi, >>>>> On Fri, 11 Mar 2005 14:19:59 -0800 >>>>> Nick Sayer said: nsayer> I've come up with the attached patch. It simply allows you to optionally nsayer> neuter the RFC-1918 checks. The problem is that there are some instances nsayer> where those checks would still be good to have - specifically, in the nsayer> code that checks IPv6 prefixes of incoming packets. There's no reason to nsayer> allow RFC-1918 addresses to appear there. But being able to be selective nsayer> would mean having to do a bit more rearchitecture than I feel like, at nsayer> least today. :-) I posted my proposed patch to current@ for review in the past. But, no one responded. Could you test this? This is for 6-CURRENT at Feb 1. If it doesn't apply cleanly, please let me know. Index: share/man/man4/stf.4 diff -u share/man/man4/stf.4.orig share/man/man4/stf.4 --- share/man/man4/stf.4.orig Sat Jan 4 14:15:26 2003 +++ share/man/man4/stf.4 Tue Feb 1 02:05:05 2005 @@ -178,6 +178,17 @@ Note, however, there are other security risks exist. If you wish to use the configuration, you must not advertise your 6to4 address to others. +.Pp +You can configure to use 6to4 from behind NAT by setting the +.Xr sysctl 8 +variable +.Va net.link.stf.no_addr4check +to 1 with support of your NAT box. In this case, make sure to use a +6to4 address which is worked out from an IPv4 global address of your +NAT box. If you are directly connected to the Internet, you shouldn't +chenge the value of +.Va net.link.stf.no_addr4check . +This is only hack to use 6to4 from within a NAT. .\" .Sh EXAMPLES Note that Index: sys/net/if_stf.c diff -u -p sys/net/if_stf.c.orig sys/net/if_stf.c --- sys/net/if_stf.c.orig Thu Jan 13 00:47:31 2005 +++ sys/net/if_stf.c Tue Feb 1 04:00:34 2005 @@ -89,6 +89,7 @@ #include #include #include +#include #include #include @@ -183,6 +184,13 @@ static int stf_clone_destroy(struct if_c struct if_clone stf_cloner = IFC_CLONE_INITIALIZER(STFNAME, NULL, 0, NULL, stf_clone_match, stf_clone_create, stf_clone_destroy); +SYSCTL_DECL(_net_link); +SYSCTL_NODE(_net_link, IFT_STF, stf, CTLFLAG_RW, 0, "6to4 Interface"); + +static int no_addr4check = 0; +SYSCTL_INT(_net_link_stf, OID_AUTO, no_addr4check, CTLFLAG_RW, + &no_addr4check, 0, "Skip checking outer IPv4 address"); + static int stf_clone_match(struct if_clone *ifc, const char *name) { @@ -357,9 +365,17 @@ stf_encapcheck(m, off, proto, arg) * local 6to4 address. * success on: dst = 10.1.1.1, ia6->ia_addr = 2002:0a01:0101:... */ - if (bcmp(GET_V4(&ia6->ia_addr.sin6_addr), &ip.ip_dst, - sizeof(ip.ip_dst)) != 0) - return 0; + if (no_addr4check) { + struct ifnet *tif; + + INADDR_TO_IFP(ip.ip_dst, tif); + if (!tif) + return 0; + } else { + if (bcmp(GET_V4(&ia6->ia_addr.sin6_addr), &ip.ip_dst, + sizeof(ip.ip_dst)) != 0) + return 0; + } /* * check if IPv4 src matches the IPv4 address derived from the @@ -401,12 +417,14 @@ stf_getsrcifa6(ifp) if (!IN6_IS_ADDR_6TO4(&sin6->sin6_addr)) continue; - bcopy(GET_V4(&sin6->sin6_addr), &in, sizeof(in)); - LIST_FOREACH(ia4, INADDR_HASH(in.s_addr), ia_hash) - if (ia4->ia_addr.sin_addr.s_addr == in.s_addr) - break; - if (ia4 == NULL) - continue; + if (!no_addr4check) { + bcopy(GET_V4(&sin6->sin6_addr), &in, sizeof(in)); + LIST_FOREACH(ia4, INADDR_HASH(in.s_addr), ia_hash) + if (ia4->ia_addr.sin_addr.s_addr == in.s_addr) + break; + if (ia4 == NULL) + continue; + } return (struct in6_ifaddr *)ia; } @@ -511,8 +529,10 @@ stf_output(ifp, m, dst, rt) bzero(ip, sizeof(*ip)); - bcopy(GET_V4(&((struct sockaddr_in6 *)&ia6->ia_addr)->sin6_addr), - &ip->ip_src, sizeof(ip->ip_src)); + if (!no_addr4check) + bcopy(GET_V4( + &((struct sockaddr_in6 *)&ia6->ia_addr)->sin6_addr), + &ip->ip_src, sizeof(ip->ip_src)); bcopy(&in4, &ip->ip_dst, sizeof(ip->ip_dst)); ip->ip_p = IPPROTO_IPV6; ip->ip_ttl = ip_stf_ttl; @@ -587,13 +607,6 @@ stf_checkaddr4(sc, in, inifp) } /* - * reject packets with private address range. - * (requirement from RFC3056 section 2 1st paragraph) - */ - if (isrfc1918addr(in)) - return -1; - - /* * reject packets with broadcast */ for (ia4 = TAILQ_FIRST(&in_ifaddrhead); @@ -645,7 +658,16 @@ stf_checkaddr6(sc, in6, inifp) */ if (IN6_IS_ADDR_6TO4(in6)) { struct in_addr in4; + bcopy(GET_V4(in6), &in4, sizeof(in4)); + + /* + * reject packets with private address range. + * (requirement from RFC3056 section 2 1st paragraph) + */ + if (isrfc1918addr(&in4)) + return -1; + return stf_checkaddr4(sc, &in4, inifp); } @@ -694,6 +716,18 @@ in_stf_input(m, off) #ifdef MAC mac_create_mbuf_from_ifnet(ifp, m); #endif + + /* + * Skip RFC1918 check against dest address to allow incoming + * packets with private address for dest. Though it may + * breasks the requirement from RFC3056 section 2 1st + * paragraph, it helps for 6to4 over NAT. + */ + if ((!no_addr4check && isrfc1918addr(&ip->ip_dst)) || + isrfc1918addr(&ip->ip_src)) { + m_freem(m); + return; + } /* * perform sanity check against outer src/dst. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 23:22:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94FD516A4CE for ; Fri, 11 Mar 2005 23:22:30 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36A9743D54 for ; Fri, 11 Mar 2005 23:22:30 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 35F7915C9E for ; Fri, 11 Mar 2005 17:21:55 -0600 (CST) Received: from 81.84.174.5 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Fri, 11 Mar 2005 17:21:55 -0600 (CST) Message-ID: <62680.81.84.174.5.1110583315.squirrel@mail.revolutionsp.com> In-Reply-To: References: <61969.81.84.174.5.1110478195.squirrel@mail.revolutionsp.com> Date: Fri, 11 Mar 2005 17:21:55 -0600 (CST) From: "H. S." To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: basic programming questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 23:22:30 -0000 Hey, thanks a lot man, really appreciated :-) Meanwhile the program has it's base already working, very nice since I didn't touch C for quite some time now (I used to program when I was younger, then shifted to system administration and shell scripting), but I'm enjoying getting things done on my own :) By the way, you know a link for a good and complete C manual for free ? Oh, and BTW. I've ran across a problem. I think I knew how to fix this, but it's beating me right now. Near the end of main() I printf'd some text and am expecting a y/n response from user. I scanf("%c", &userfeed); right after, but it printf's and ignores the scanf. I might know what's going on, some characters on the buffer are not "cleared", and so scanf is beind fed one of these characters. My memory says that fflush() should fix this, but it's not working. I've also tried getchar() but it didn't work either (or I did it in a wrong way).. I'm missing something obvious here! What should I do to correct this? And is my buffer-not-empty-so-scanf-gets-a-waiting-character theory correct ? Your curses program and the links the other people gave were great, thanks to all :) > On Thu, 10 Mar 2005, H. S. wrote: > >>Hey, >> >>Sorry if this is a little offtopic, but I need some basic help with C. >> >>I'm not a programmer, but I need to get something done in C for a >> project. >>I need to do a console application, and as I've got some free time, I'd >>like to add bold sentences and characters with other colors (ie blue, >> red, >>etc), to make it prettier. >> >>As my C skills go as far as declaring variables, making loops, and >> knowing >>my way around pointers, I really do not know where to start looking for >>the header file including these functions! I also need a function to >> clear >>the screen (in order to re-draw it). >> >>Could anyone point me to the right header files, and perhaps suggest some >>programs that use these functions so I can have something to start with? > > > Here's a little program I just wrote for you: > > > #include > > main() > { > initscr(); > start_color(); > > /* we want blue text on a white background */ > init_pair(1, COLOR_BLUE, COLOR_WHITE); > color_set(1, NULL); > > clear(); > > mvprintw(10,20, "Hello, world"); > refresh(); > > endwin(); > } > > > I compiled with: > > cc -o test test.c -lncurses > > and it demonstrates what you want :- clearing the screen and writing text > in color at a specific location (10 down, 20 across.) > > If you don't need to position the text, you can use plain "printw" without > the x,y. printw is like printf. > > Hope this helps, > > Aled > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 00:38:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 702CE16A4CE for ; Sat, 12 Mar 2005 00:38:38 +0000 (GMT) Received: from mx2.netflix.com (mail2.netflix.com [216.35.131.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 553F443D48 for ; Sat, 12 Mar 2005 00:38:38 +0000 (GMT) (envelope-from nsayer@kfu.com) Received: from [172.22.8.180] ([172.22.8.180]) by mx2.netflix.com (8.12.8/8.12.8) with ESMTP id j2C0cbKD001481 for ; Fri, 11 Mar 2005 16:38:37 -0800 Message-ID: <42323A0D.8060501@kfu.com> Date: Fri, 11 Mar 2005 16:38:37 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4232198F.5030705@kfu.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 6to4, stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 00:38:38 -0000 Hajimu UMEMOTO wrote: >I posted my proposed patch to current@ for review in the past. But, >no one responded. Could you test this? This is for 6-CURRENT at Feb 1. >If it doesn't apply cleanly, please let me know. > > Domo arigato gozaimasu! It had fuzz when applied to 5.3-RELEASE, but it did apply. I am at work, behind the wrong firewall, so I cannot test this completely, but with your patch applied and turned on, I can see that configuring my machine (which lives in 172.16 space) with a "foreign" 6to4 prefix on stf0 results in ping6 packets being transmitted correctly (tcpdump shows a correct ipv6 packet and shows an ipv4 header with the packet being from my 172.16 machine and going to the correct destination). I have high hopes that the return side will work when it's deployed for real. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 07:27:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B184216A4CE for ; Sat, 12 Mar 2005 07:27:00 +0000 (GMT) Received: from quack.kfu.com (quack.kfu.com [64.168.71.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id E51FF43D1D for ; Sat, 12 Mar 2005 07:26:59 +0000 (GMT) (envelope-from nsayer@kfu.com) Received: from [IPv6:2002:40a8:47d1:1:206:25ff:fe3d:aa11] (minerva.kfu.com [IPv6:2002:40a8:47d1:1:206:25ff:fe3d:aa11]) (authenticated bits=0) by quack.kfu.com (8.12.10/8.12.10) with ESMTP id j2C7Q1d8001325 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 11 Mar 2005 23:26:02 -0800 (PST) (envelope-from nsayer@kfu.com) X-Message-Flag: Why aren't you using a Macintosh yet? In-Reply-To: <42323A0D.8060501@kfu.com> References: <4232198F.5030705@kfu.com> <42323A0D.8060501@kfu.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--838892915; protocol="application/pkcs7-signature" Message-Id: <831b85e9533de2bb477712153a9eb99a@kfu.com> From: Nick Sayer Date: Fri, 11 Mar 2005 23:24:52 -0800 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.619.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: 6to4, stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 07:27:00 -0000 --Apple-Mail-5--838892915 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Well, I'm screwed. I set up the Linksys router so that the FreeBSD machine is the "DMZ" host on the inside. Sending 6to4 to the router's outside address results in tcpdump showing these on the inside: 22:09:36.138924 [linksys mac address] > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has [linksys outside ip] tell [linksys inside ip] Which, quite frankly, is laughable. If that weren't enough, the packets come out of the linksys router with the source IP address being from the inside (meaning, it didn't get NATted). Humph. So it appears that for now, I will have to keep a 2nd interface active on this box solely for the purpose of doing IPv6. What a nightmare. On Mar 11, 2005, at 4:38 PM, Nick Sayer wrote: > Hajimu UMEMOTO wrote: > >> I posted my proposed patch to current@ for review in the past. But, >> no one responded. Could you test this? This is for 6-CURRENT at Feb >> 1. >> If it doesn't apply cleanly, please let me know. >> > Domo arigato gozaimasu! > > It had fuzz when applied to 5.3-RELEASE, but it did apply. > > I am at work, behind the wrong firewall, so I cannot test this > completely, but with your patch applied and turned on, I can see that > configuring my machine (which lives in 172.16 space) with a "foreign" > 6to4 prefix on stf0 results in ping6 packets being transmitted > correctly (tcpdump shows a correct ipv6 packet and shows an ipv4 > header with the packet being from my 172.16 machine and going to the > correct destination). I have high hopes that the return side will work > when it's deployed for real. > > _______________________________________________ > 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" --Apple-Mail-5--838892915-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 09:48:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1746D16A4CE for ; Sat, 12 Mar 2005 09:48:16 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id A96AC43D48 for ; Sat, 12 Mar 2005 09:48:14 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)j2C9m502056926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2005 18:48:05 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 12 Mar 2005 18:48:04 +0900 Message-ID: From: Hajimu UMEMOTO To: Nick Sayer In-Reply-To: <831b85e9533de2bb477712153a9eb99a@kfu.com> References: <4232198F.5030705@kfu.com> <42323A0D.8060501@kfu.com> <831b85e9533de2bb477712153a9eb99a@kfu.com> User-Agent: xcite1.38> Wanderlust/2.13.3 (You Oughta Know) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-PRERELEASE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b2 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 12 Mar 2005 18:48:05 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on cheer.mahoroba.org cc: freebsd-hackers@freebsd.org Subject: Re: 6to4, stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 09:48:16 -0000 Hi, >>>>> On Fri, 11 Mar 2005 23:24:52 -0800 >>>>> Nick Sayer said: nsayer> Well, I'm screwed. nsayer> I set up the Linksys router so that the FreeBSD machine is the "DMZ" nsayer> host on the inside. Sending 6to4 to the router's outside address nsayer> results in tcpdump showing these on the inside: nsayer> 22:09:36.138924 [linksys mac address] > ff:ff:ff:ff:ff:ff, ethertype nsayer> ARP (0x0806), length 60: arp who-has [linksys outside ip] tell [linksys nsayer> inside ip] nsayer> Which, quite frankly, is laughable. If that weren't enough, the packets nsayer> come out of the linksys router with the source IP address being from nsayer> the inside (meaning, it didn't get NATted). Humph. nsayer> So it appears that for now, I will have to keep a 2nd interface active nsayer> on this box solely for the purpose of doing IPv6. What a nightmare. It seems your Linksys box simply forward packets without translating destination address to your 6to4 box. I don't know actually what DMZ concept of Linksys is. However, you may need some additional setting into your Linksys box. Or, when you just set global addres of your Linksys box to your 6to4 box, you may be able to use 6to4 without my patch. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 15:27:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6DE716A4CE; Fri, 11 Mar 2005 15:27:36 +0000 (GMT) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id A625243D39; Fri, 11 Mar 2005 15:27:36 +0000 (GMT) (envelope-from rees@citi.umich.edu) Received: from citi.umich.edu (dumaguete.citi.umich.edu [141.211.133.51]) by citi.umich.edu (Postfix) with ESMTP id 63E7E1BB8B; Fri, 11 Mar 2005 10:27:36 -0500 (EST) To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org From: Jim Rees In-Reply-To: Adam Maloney, Fri, 11 Mar 2005 09:02:06 CST Date: Fri, 11 Mar 2005 10:27:36 -0500 Sender: rees@citi.umich.edu Message-Id: <20050311152736.63E7E1BB8B@citi.umich.edu> X-Mailman-Approved-At: Sat, 12 Mar 2005 13:04:38 +0000 Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:27:36 -0000 There are OpenAFS and NFSv4 clients for FreeBSD, but unfortunately neither is really production quality. It wouldn't take much to make at least the OpenAFS client usable but no one seems to be working on it now. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 19:16:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E784916A4CE for ; Fri, 11 Mar 2005 19:16:37 +0000 (GMT) Received: from mx2.netflix.com (mail2.netflix.com [216.35.131.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD96643D1D for ; Fri, 11 Mar 2005 19:16:37 +0000 (GMT) (envelope-from nsayer@kfu.com) Received: from [172.22.8.180] ([172.22.8.180]) by mx2.netflix.com (8.12.8/8.12.8) with ESMTP id j2BJGaKD027116 for ; Fri, 11 Mar 2005 11:16:37 -0800 Message-ID: <4231EE94.8050601@kfu.com> Date: Fri, 11 Mar 2005 11:16:36 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 12 Mar 2005 13:04:38 +0000 Subject: stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 19:16:38 -0000 Historically, I've used FreeBSD machines as NAT routers. Call me a traitor if you must, but it's getting harder to justify not simply putting one of those little Linksys/Netgear/SMC/whatever NAT routers in place and having the FreeBSD machine be a server behind the box instead. One of the last considerations remaining is IPv6. Most boxes now have the concept of a "DMZ" host. They will, aparently, perform simple address substitution on the IP header for packets that arrive of an unknown protocol and send them to the DMZ host (living on the inside LAN - thus calling it a DMZ host is a bit of a misnomer, but that's a semantic debate for another occasion). This would be ideal for 6to4 - incoming packets would simply arrive and be processed. The trouble appears to be the outgoing side. The machine's actual IPv4 address is not the same as the *outside* IPv4 address, so one of two things is happening (I'm not sure which): Either the blanket prohibition on RFC-1918 addresses having anything to do with 6to4 is getting in the way, or stf0 having a "foreign" prefix (that is, a prefix that does not relate to a physical interface on the machine) is confusing it. 6to4 is the IPv6 connection solution I prefer. Is there any way stf can be taught to live behind an IPv4 NAT? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 19:20:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D26116A4CE for ; Fri, 11 Mar 2005 19:20:25 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5E0D43D5D for ; Fri, 11 Mar 2005 19:20:24 +0000 (GMT) (envelope-from phreaki@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so1485839rne for ; Fri, 11 Mar 2005 11:20:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Mm/Izobz/V0u3OaE/zY+xJiy03MLQ/UkBSlT3MJ5p8Yp6tDCSXKOoNAuLB+zE2QP3PwWG725btcH64pqE8wIN2G4n+JtzmHim2uQ+Ea7yiKw9xczBWM42SNUjZnaQD3/LENMlJhHxrz7Jbqgd48xKG0Nfcy1s9y7/f+z7ZAFjgM= Received: by 10.11.100.28 with SMTP id x28mr136935cwb; Fri, 11 Mar 2005 11:20:24 -0800 (PST) Received: by 10.11.120.23 with HTTP; Fri, 11 Mar 2005 11:20:24 -0800 (PST) Message-ID: <6fb2b4650503111120760d9335@mail.gmail.com> Date: Fri, 11 Mar 2005 14:20:24 -0500 From: Robert Atkinson To: Florent Thoumie In-Reply-To: <4231B7D5.3070306@xbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4231B19D.8060406@centtech.com> <4231B7D5.3070306@xbsd.org> X-Mailman-Approved-At: Sat, 12 Mar 2005 13:04:38 +0000 cc: freebsd-fs@freebsd.org cc: Eric Anderson cc: freebsd-hackers@freebsd.org Subject: Re: Global / Cluster / Shared filesystem for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Robert Atkinson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 19:20:25 -0000 I'm still lurking and hoping the new GEOM will be used for such a system. On Fri, 11 Mar 2005 16:23:01 +0100, Florent Thoumie wrote: > Adam Maloney wrote: > > On Fri, 11 Mar 2005, Eric Anderson wrote: > > > >> Speaking of filesytems :), I have a real need for a global filesystem > >> (or > > > > > > "me too" > > > > I played with CODA a few months ago but it didn't seem to be solid, and > > didn't fit my needs. Everything else I've looked at is Linux-only. > > Please follow-up to the list, I'd be very interested in seeing what > > other projects are available. > > _______________________________________________ > > 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 don't know if DRBD [1] is a good implementation (Linux only), but it > works flawlessly, replication is fast (i got ~35MB/s) and it's quite > simple to get it working. > > ENBD [2] isn't based on the same concept, it "exports" block devices > through network via userland application, though it needs a kernel > module for client side. > > I'd like something like DRBD exists for FreeBSD but I'm not aware of > such an implementation. > > [1] http://www.drbd.org/ > [2] http://www.it.uc3m.es/~ptb/nbd/ > > -- flz > > > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 14:03:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B99116A4CE for ; Sat, 12 Mar 2005 14:03:59 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C22E43D39 for ; Sat, 12 Mar 2005 14:03:59 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id BE32415CA0 for ; Sat, 12 Mar 2005 08:03:23 -0600 (CST) Received: from 81.84.174.5 (SquirrelMail authenticated user security@revolutionsp.com) by mail.revolutionsp.com with HTTP; Sat, 12 Mar 2005 08:03:23 -0600 (CST) Message-ID: <63687.81.84.174.5.1110636203.squirrel@mail.revolutionsp.com> Date: Sat, 12 Mar 2005 08:03:23 -0600 (CST) From: "H. S." To: freebsd-hackers@FreeBSD.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: IP packets from host system showing inside a jail? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 14:03:59 -0000 Hey, I've noticed something odd.. I'm using FreeBSD 5.3-STABLE with PF, on a dual xeon 2.4 system. I have two jails running for web and mail servers. Today I was testing something and needed a tcpdump, so inside a jail I started tcpdump as root. To my amazement, IP packets from the host system (IRC connections that should NOT show on that jail) were appearing on the tcpdump INSIDE the jail! tcpdump then became irresponsive quickly after capturing those, ^C wouldn't kill it and ^Z didn't nothing either. I had to login from another terminal to the host system, and killall -KILL tcpdump. Is this a known bug? IP packets from the host system<->internet should not be visible inside the jail. If you need tcpdump/uname -a etc, I'll provide these when asked. Regards From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 16:40:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF16716A4CE for ; Sat, 12 Mar 2005 16:40:19 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id E643043D1D for ; Sat, 12 Mar 2005 16:40:18 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DA9ez-0006q4-00; Sat, 12 Mar 2005 17:40:17 +0100 Received: from [217.227.158.161] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DA9ey-0000gs-00; Sat, 12 Mar 2005 17:40:17 +0100 From: Max Laier To: freebsd-hackers@freebsd.org Date: Sat, 12 Mar 2005 17:40:06 +0100 User-Agent: KMail/1.7.2 References: <63687.81.84.174.5.1110636203.squirrel@mail.revolutionsp.com> In-Reply-To: <63687.81.84.174.5.1110636203.squirrel@mail.revolutionsp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5322373.QeXrN1cgP9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503121740.12605.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: "H. S." Subject: Re: IP packets from host system showing inside a jail? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 16:40:20 -0000 --nextPart5322373.QeXrN1cgP9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 12 March 2005 15:03, H. S. wrote: > Hey, > > I've noticed something odd.. I'm using FreeBSD 5.3-STABLE with PF, on a > dual xeon 2.4 system. I have two jails running for web and mail servers. > Today I was testing something and needed a tcpdump, so inside a jail I > started tcpdump as root. > > To my amazement, IP packets from the host system (IRC connections that > should NOT show on that jail) were appearing on the tcpdump INSIDE the > jail! > > tcpdump then became irresponsive quickly after capturing those, ^C > wouldn't kill it and ^Z didn't nothing either. I had to login from another > terminal to the host system, and killall -KILL tcpdump. > > Is this a known bug? IP packets from the host system<->internet should not > be visible inside the jail. > > If you need tcpdump/uname -a etc, I'll provide these when asked. tcpdump reads "raw" data from the hardware useing the bpf socket. There is= no=20 way (implemented) to filter bpf for jails. It'd be also a bit tricky to=20 realize as bpf sees "raw" i.e. ethernet packets while jails are a IP-level= =20 construct, so in order to filter bpf for jails one would have to do a lot o= f=20 extra work. I don't think there is a "legal" application for bpf inside of= a=20 jail that would justify the additional work. The only way to avoid this, is to not give your jail(s) access to /dev/bpf = =2D=20 why would you want to in the first place? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5322373.QeXrN1cgP9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCMxtsXyyEoT62BG0RAmGnAJsGIqLQvfvPag0gbmzxb/SYvsFXtwCfQKDT dYw1qR14Jou4z1MbdwAN2sc= =tDpM -----END PGP SIGNATURE----- --nextPart5322373.QeXrN1cgP9-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 18:12:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1D6816A4CE for ; Sat, 12 Mar 2005 18:12:22 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88F6343D31 for ; Sat, 12 Mar 2005 18:12:21 +0000 (GMT) (envelope-from alexjeffburke@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1282908wra for ; Sat, 12 Mar 2005 10:12:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=LOSqRXwjrQAWvz7rqXjbfv/IHRi4dJ4fq4nR2QSUvvUZTQOIMot1owPQ1ZfDc0dNn1YoPY9sQ4k7dzuG4sBQqzmlqJhXSH40HixERp+h6o/v8bG7rU5OQl6v6H2lg9K6ws4qoN/sWY79J0ZY/HVzGQ+s7VbrjGUJLZYEUJW1QRQ= Received: by 10.54.77.7 with SMTP id z7mr757732wra; Sat, 12 Mar 2005 10:12:19 -0800 (PST) Received: by 10.54.37.43 with HTTP; Sat, 12 Mar 2005 10:12:19 -0800 (PST) Message-ID: Date: Sat, 12 Mar 2005 18:12:19 +0000 From: Alex Burke To: FreeBSD-HACKERS Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Low level hardware access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alex Burke List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 18:12:22 -0000 Hi, I am just wondering how I can access either BIOS calls, or preferably registers under FreeBSD? I am trying to write a simple system capable of displaying graphics on the screen, and I am pretty sure I can mmap the VGA memory to my programs address space. However, to be able to output graphics onto the screen I think I need to change the state of the VGA registers from text mode (I am guessing thats what the console driver uses) to graphical mode (of which i know there exist a couple) - but I think that involves programming registers and I dont know how to do that under FreeBSD. Also, for the FreeBSD console driver to pick the console back up once it finished working, would I be required to reset the VGA registers back to text mode? Thanks, Alex J Burke. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 18:44:27 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C33A16A4CE for ; Sat, 12 Mar 2005 18:44:27 +0000 (GMT) Received: from vsmtp14.tin.it (vsmtp14.tin.it [212.216.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id E23D843D48 for ; Sat, 12 Mar 2005 18:44:26 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp14.tin.it (7.0.027) id 4227B878003AFA6E; Sat, 12 Mar 2005 19:44:24 +0100 Received: from [192.168.70.181] by ims3a.cp.tin.it with HTTP; Sat, 12 Mar 2005 19:44:23 +0100 Date: Sat, 12 Mar 2005 19:44:23 +0100 Message-ID: <4200084500050550@ims3a.cp.tin.it> In-Reply-To: From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Originating-IP: 82.91.74.60 cc: alexjeffburke@gmail.com Subject: RE: Low level hardware access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 18:44:27 -0000 >Hi, > >I am just wondering how I can access either BIOS calls, or preferably >registers under FreeBSD? > >I am trying to write a simple system capable of displaying graphics on >the screen, and I am pretty sure I can mmap the VGA memory to my >programs address space. > >However, to be able to output graphics onto the screen I think I need >to change the state of the VGA registers from text mode (I am guessing >thats what the console driver uses) to graphical mode (of which i know >there exist a couple) - but I think that involves programming >registers and I dont know how to do that under FreeBSD. > >Also, for the FreeBSD console driver to pick the console back up once >it finished working, would I be required to reset the VGA registers >back to text mode? > >Thanks, Alex J Burke. FreeBSD runs in protected mode (for x86 processors) so you can't access to BIOS calls directly. You maybe need to see IN/OUT requests for VGA por= t. rookie From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 18:47:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C9F616A4CE for ; Sat, 12 Mar 2005 18:47:06 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B379643D3F for ; Sat, 12 Mar 2005 18:47:05 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 26057 invoked from network); 12 Mar 2005 18:47:05 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Mar 2005 18:47:05 -0000 Received: from hydrogen.funkthat.com (pcryty@localhost.funkthat.com [127.0.0.1])j2CIl3GH058549; Sat, 12 Mar 2005 10:47:04 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j2CIl3gg058548; Sat, 12 Mar 2005 10:47:03 -0800 (PST) Date: Sat, 12 Mar 2005 10:47:03 -0800 From: John-Mark Gurney To: Alex Burke Message-ID: <20050312184703.GV89312@funkthat.com> Mail-Followup-To: Alex Burke , FreeBSD-HACKERS References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: FreeBSD-HACKERS Subject: Re: Low level hardware access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 18:47:06 -0000 Alex Burke wrote this message on Sat, Mar 12, 2005 at 18:12 +0000: > I am just wondering how I can access either BIOS calls, or preferably > registers under FreeBSD? > > I am trying to write a simple system capable of displaying graphics on > the screen, and I am pretty sure I can mmap the VGA memory to my > programs address space. correct, you can do this by opening /dev/mem... > However, to be able to output graphics onto the screen I think I need > to change the state of the VGA registers from text mode (I am guessing > thats what the console driver uses) to graphical mode (of which i know > there exist a couple) - but I think that involves programming > registers and I dont know how to do that under FreeBSD. You don't want to access the registers directly because then you could get syscons confused on what the state is... Take a look at vidcontrol.. You can use ioctl's documented in sys/fbio.h to change modes... > Also, for the FreeBSD console driver to pick the console back up once > it finished working, would I be required to reset the VGA registers > back to text mode? If you use the sys/fbio.h ioctl's you'll need to do that... I also found, that you have to becareful to restore the video mode. Sometimes your app will segfault, and won't restore the video display, but the machine is still running.. You can also check out svgalib or sdl in ports... They also provide the ability to do console graphics... sdl I believe can also run under X11 which can be useful. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 19:16:44 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27F0516A4CE; Sat, 12 Mar 2005 19:16:44 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41BBE43D1F; Sat, 12 Mar 2005 19:16:43 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id j2CJGgOZ051606; Sat, 12 Mar 2005 11:16:43 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <4233401A.3040403@freebsd.org> Date: Sat, 12 Mar 2005 11:16:42 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20050311152951.GA90290@freefall.freebsd.org> In-Reply-To: <20050311152951.GA90290@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD trusted execution system: beta testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 19:16:44 -0000 Christian S.J. Peron wrote: > > I have written a trusted execution module and would appreciate if anyone could > help in testing. This module provides a functionality similar to NetBSD's > verified exec mechanism. Excellent! Sounds like something that could provide a lot of additional protection against trojans and worms. Wish I had time to play with it right now.... Tim From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 12 23:06:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E346E16A4CE; Sat, 12 Mar 2005 23:06:25 +0000 (GMT) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id C108643D5C; Sat, 12 Mar 2005 23:06:24 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2CN6Mo8032318 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 13 Mar 2005 10:06:23 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2CN6L7l023341; Sun, 13 Mar 2005 10:06:21 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2CN6L8W023340; Sun, 13 Mar 2005 10:06:21 +1100 (EST) (envelope-from pjeremy) Date: Sun, 13 Mar 2005 10:06:21 +1100 From: Peter Jeremy To: "Christian S.J. Peron" Message-ID: <20050312230621.GA17852@cirb503493.alcatel.com.au> References: <20050311152951.GA90290@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050311152951.GA90290@freefall.freebsd.org> User-Agent: Mutt/1.4.2i cc: freebsd-security@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD trusted execution system: beta testers wanted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 23:06:26 -0000 On Fri, 2005-Mar-11 15:29:51 +0000, Christian S.J. Peron wrote: >I have written a trusted execution module and would appreciate if anyone could >help in testing. This module provides a functionality similar to NetBSD's >verified exec mechanism. Once the design details of this security policy has >been solidified, I will be releasing a white paper which describes the >technical implementation in greater detail. Sounds good. > Download, build and install the mac_chkexec kernel module: > > fetch http://people.freebsd.org/~csjp/mac/mac_chkexec.1110510616.tar.gz > tar zxvf mac_chkexec.1110510616.tar.gz > cd mac_chkexec > make > make install Unfortunately, the existing file is incompatible with the "standard" kernel building process. The instructions above seem to work but since it's a separate step from buildkernel/installkernel, I'm sure to forget it at some time. If I unpack it into /sys/modules and add "SUBDIR += mac_chkexec" to /sys/modules/Makefile - it blows up with: ===> mac_chkexec @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/src/sys/crypto -D_KERNEL -DKLD_MODULE -I- -I/usr/src/sys/crypto -I. -I@ -I@/contrib/altq -I@/../include -I/usr/obj/usr/src/i386/usr/include -I/usr/obj/usr/src/sys/fwall /usr/src/sys/crypto//sha1.c /usr/src/sys/modules/mac_chkexec/mac_chkexec.c /usr/src/sys/modules/mac_chkexec/mac_chkexec.c:61:25: mac_chkexec.h: No such file or directory mkdep: compile failed *** Error code 1 I also notice that the Makefile has /usr/src/sys hard-coded into it. Can I suggest the following patch: server# diff -u Makefile~ Makefile --- Makefile~ Fri Mar 11 14:09:20 2005 +++ Makefile Sun Mar 13 09:56:42 2005 @@ -1,5 +1,5 @@ -.PATH: /usr/src/sys/crypto/ -CFLAGS+= -I/usr/src/sys/crypto +.PATH: ${.CURDIR}/../../crypto +CFLAGS+= -I${.CURDIR} -I${.CURDIR}/../../crypto KMOD= mac_chkexec SRCS= vnode_if.h \ server# -- Peter Jeremy