From owner-freebsd-hackers Sun Aug 19 1:59:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by hub.freebsd.org (Postfix) with ESMTP id 2AA4E37B416; Sun, 19 Aug 2001 01:59:20 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id KAA19854; Sun, 19 Aug 2001 10:59:16 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.4/8.11.4) id f7J8xB913709; Sun, 19 Aug 2001 10:59:11 +0200 (CEST) (envelope-from wkb) Date: Sun, 19 Aug 2001 10:59:11 +0200 From: Wilko Bulte To: Leo Bicknell Cc: Matt Dillon , hackers@FreeBSD.ORG, murray@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Recommendation for minor KVM adjustments for the release Message-ID: <20010819105911.A13675@freebie.xs4all.nl> References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818205925.B82967@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010818205925.B82967@ussenterprise.ufp.org>; from bicknell@ufp.org on Sat, Aug 18, 2001 at 08:59:25PM -0400 X-OS: FreeBSD 4.3-STABLE 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 Sat, Aug 18, 2001 at 08:59:25PM -0400, Leo Bicknell wrote: > On Sat, Aug 18, 2001 at 08:49:55AM -0700, Matt Dillon wrote: > > - I would like to cap the SWAPMETA zone reservation to 70MB, > > which allows us to manage a maximum of 29GB worth of swapped > > out data. > > Not to introduce machine dependancy, but on Intel max ram is 4GB, > so it seems to me that 8-12GB total space (4-8GB swap) would be an > outside value. Alphas can have more RAM, although I doubt few do. FYI: FreeBSD/alpha currently is limited to <= 2GB of physical RAM. -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 3: 7:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from root.com (unknown [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id BFB2337B406; Sun, 19 Aug 2001 03:07:31 -0700 (PDT) (envelope-from dg@root.com) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id f7J9q0f80304; Sun, 19 Aug 2001 02:52:00 -0700 (PDT) (envelope-from dg) Date: Sun, 19 Aug 2001 02:52:00 -0700 From: David Greenman To: Sergey Babkin Cc: Matt Dillon , hackers@freebsd.org, murray@freebsd.org, jkh@freebsd.org Subject: Re: Recommendation for minor KVM adjustments for the release Message-ID: <20010819025200.C76779@nexus.root.com> References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.com> <3B7F0F1E.45A25AC5@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B7F0F1E.45A25AC5@bellatlantic.net>; from babkin@bellatlantic.net on Sat, Aug 18, 2001 at 08:58:06PM -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 >David Greenman wrote: >> >> > - I would like to cap the size of the buffer cache at 200MB, >> > giving us another 70MB or so of KVM which is equivalent to >> > another 30,000 or so nmbclusters. >> >> That also seems like overkill for the vast majority of systems. > >But probably not for the large-memory systems (and on the machines >with small memory the limit will be smaller anyway). Having a >machine with a few gigs of memory and being able to use only 200MB >for the buffer cache seems to be quite bad for a general-purpose >machine. Uh, I don't think you understand what this limit is about. It's essentially the limit on the amount of filesystem directory data that can be cached. It does not limit the amount of file data that can be cached - that is only limited by the amount of RAM in the machine. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 6:15: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from enterprise.spock.org (cm-24-29-85-81.nycap.rr.com [24.29.85.81]) by hub.freebsd.org (Postfix) with ESMTP id 9273C37B409; Sun, 19 Aug 2001 06:14:59 -0700 (PDT) (envelope-from jon@enterprise.spock.org) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Sun, 19 Aug 2001 09:14:52 -0400 (EDT) (envelope-from jon)$ Date: Sun, 19 Aug 2001 09:14:52 -0400 From: Jonathan Chen To: Sam Habash Cc: freebsd-gnats-submit@FreeBSD.ORG, mobile@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kern/24854: NEWCARD support for aironet driver an(4) Message-ID: <20010819091452.A86632@enterprise.spock.org> References: <20010817011103.A25841@llama.com> <20010818110728.A20719@enterprise.spock.org> <20010818092654.C28694@llama.com> <20010818124503.A26350@enterprise.spock.org> <20010818212011.A33879@llama.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <20010818212011.A33879@llama.com>; from the@llama.com on Sat, Aug 18, 2001 at 09:20:11PM -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 [summary of past events for the benefit of gnats] - original PR filed for Cisco aironet not working under newcard - My LMC342 works just fine, and I though this might be a bug in newcard (as opposed to the an driver as suggested in the pr), suggested Sam to try the updated newcard (http://people.freebsd.org/~jon/newcard.diff.3) - this patch makes an work under newcard without the proposed changes in the pr. > I believe I already tried just uncommenting 'optional ata pccard' > with the -current source, without any luck. Sam, I'm not sure what you mean here. > The first time I tried it (not in X) removal and reinsertion of the > Aironet card was fine. > > The second time (while in X), removal was ok, but card reinsertion caused > a reboot (no panic)... > > Let me know what you want me to do exactly, in terms of what kind of > debugging you need...once I hear back I'll build a debug kernel. Are you sure there is no panic while in X? Your X server might have futzed with the video card so you might not actually see the panic. If you can try to reproduce this in text mode, then the panic message as well as a traceback would be a very good start. But before you do that, I believe I may have found a fix for a possible panic situation. This panic occurs in witness_destroy as a supervisor read page not present error (I presume while trying to dereference lock). This panic can be easily reproduced by running dhclient an0, removing and reinserting the card, then killing dhclient. The fix appears to be shockingly simple: diff -u -r1.8 if_an_pccard.c --- sys/dev/an/if_an_pccard.c 2001/05/26 09:26:58 1.8 +++ sys/dev/an/if_an_pccard.c 2001/08/19 12:57:14 @@ -118,6 +118,7 @@ sc->an_gone = 1; bus_teardown_intr(dev, sc->irq_res, sc->irq_handle); an_release_resources(dev); + mtx_destroy(&sc->an_mtx); return (0); } Here's where I require some guidance from someone in the know. While this patch appears to avoid the problem on my system, does it in fact work? How does the panic occur and how does this fix the problem, if indeed it does? I'm quite clueless as to the implementation of mutex locking on freebsd, and I suppose it's just plain luck that the first thing I tried turned out to have done the trick... -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 8:58:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 70C1937B408; Sun, 19 Aug 2001 08:58:42 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA27610; Sun, 19 Aug 2001 09:58:41 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id JAA24571; Sun, 19 Aug 2001 09:58:40 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15231.57904.53731.598691@nomad.yogotech.com> Date: Sun, 19 Aug 2001 09:58:40 -0600 To: Matt Dillon Cc: hackers@FreeBSD.ORG, murray@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Recommendation for minor KVM adjustments for the release In-Reply-To: <200108181549.f7IFntw39740@earth.backplane.com> References: <200108181549.f7IFntw39740@earth.backplane.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 would like to cap the size of the buffer cache at 200MB, > giving us another 70MB or so of KVM which is equivalent to > another 30,000 or so nmbclusters. I know of many scientific applications that were written with low-memory machines in mind, which use use lots of disk as temporary memory. It would be nice in this case to allow them to buffer up large amounts of the accessed disks in cache, instead of having them. For certain kinds of programs/loads, using up a large amount of buffer cache is a good thing, so I'd rather not see hardcoded limits on buffer cache. Yes, I know the programs will run fine w/out the additional cache, but in many of the cases, they stick a huge amount of memory into the box in an attempt to maximize performance of the box, especially w/FreeBSD vaunted 'unified VM/cache'. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 9:18:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 96F7537B401; Sun, 19 Aug 2001 09:18:32 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA27936; Sun, 19 Aug 2001 10:18:28 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA24639; Sun, 19 Aug 2001 10:18:27 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15231.59091.431242.582447@nomad.yogotech.com> Date: Sun, 19 Aug 2001 10:18:27 -0600 To: David Greenman Cc: Sergey Babkin , Matt Dillon , hackers@FreeBSD.ORG, murray@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Recommendation for minor KVM adjustments for the release In-Reply-To: <20010819025200.C76779@nexus.root.com> References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.com> <3B7F0F1E.45A25AC5@bellatlantic.net> <20010819025200.C76779@nexus.root.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 would like to cap the size of the buffer cache at 200MB, > >> > giving us another 70MB or so of KVM which is equivalent to > >> > another 30,000 or so nmbclusters. > >> > >> That also seems like overkill for the vast majority of systems. > > > >But probably not for the large-memory systems (and on the machines > >with small memory the limit will be smaller anyway). Having a > >machine with a few gigs of memory and being able to use only 200MB > >for the buffer cache seems to be quite bad for a general-purpose > >machine. > > Uh, I don't think you understand what this limit is about. It's > essentially the limit on the amount of filesystem directory data that > can be cached. It does not limit the amount of file data that can > be cached - that is only limited by the amount of RAM in the machine. Ahh, thanks for the clarification. I retract my previous email about limiting this as well. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 10:40:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from best.llama.com (llama.com [63.194.69.194]) by hub.freebsd.org (Postfix) with ESMTP id 5978337B409; Sun, 19 Aug 2001 10:40:06 -0700 (PDT) (envelope-from the@best.llama.com) Received: (from the@localhost) by best.llama.com (8.9.3/8.9.3) id KAA35563; Sun, 19 Aug 2001 10:40:06 -0700 (PDT) (envelope-from the) Date: Sun, 19 Aug 2001 10:39:55 -0700 From: Sam Habash To: Jonathan Chen Cc: freebsd-gnats-submit@FreeBSD.ORG, mobile@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kern/24854: NEWCARD support for aironet driver an(4) Message-ID: <20010819103955.A35427@llama.com> References: <20010817011103.A25841@llama.com> <20010818110728.A20719@enterprise.spock.org> <20010818092654.C28694@llama.com> <20010818124503.A26350@enterprise.spock.org> <20010818212011.A33879@llama.com> <20010819091452.A86632@enterprise.spock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010819091452.A86632@enterprise.spock.org>; from jon@FreeBSD.ORG on Sun, Aug 19, 2001 at 09:14:52AM -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 Sun, Aug 19, 2001 at 09:14:52AM -0400, Jonathan Chen wrote: > > [summary of past events for the benefit of gnats] > - original PR filed for Cisco aironet not working under newcard > - My LMC342 works just fine, and I though this might be a bug in newcard > (as opposed to the an driver as suggested in the pr), suggested Sam to > try the updated newcard (http://people.freebsd.org/~jon/newcard.diff.3) > - this patch makes an work under newcard without the proposed changes in > the pr. > > > I believe I already tried just uncommenting 'optional ata pccard' > > with the -current source, without any luck. > > Sam, I'm not sure what you mean here. What I mean here is that an unpatched -current (as of mid-August) was not resulting in detection of my LMC352. In the current sources, the following in src/sys/conf/files has been commented out: #dev/an/if_an_pccard.c optional an pccard Commenting this out and recompiling did NOT result in a successful attach, at least when I tested this in early August. I'm testing again by backing out of your patch and recompiling, and it turns out that it -does- work now, most likely this was operator error in not uncommenting the the conf/files entry, since I don't see any likely commits that would have changed anything...sigh, sorry for the waste of time. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/files.diff?r1=1.483&r2=1.484&f=h documents when the line was commented out...it's been that way for a while... > > The first time I tried it (not in X) removal and reinsertion of the > > Aironet card was fine. > > > > The second time (while in X), removal was ok, but card reinsertion caused > > a reboot (no panic)... > > > > Let me know what you want me to do exactly, in terms of what kind of > > debugging you need...once I hear back I'll build a debug kernel. > > Are you sure there is no panic while in X? Your X server might have > futzed with the video card so you might not actually see the panic. If you > can try to reproduce this in text mode, then the panic message as well as a > traceback would be a very good start. -nod- > But before you do that, I believe I may have found a fix for a possible > panic situation. This panic occurs in witness_destroy as a supervisor read > page not present error (I presume while trying to dereference lock). This > panic can be easily reproduced by running dhclient an0, removing and > reinserting the card, then killing dhclient. The fix appears to be > shockingly simple: I'll see if I can reproduce the problem in CLI mode with your patch to if_an_pccard.c > > diff -u -r1.8 if_an_pccard.c > --- sys/dev/an/if_an_pccard.c 2001/05/26 09:26:58 1.8 > +++ sys/dev/an/if_an_pccard.c 2001/08/19 12:57:14 > @@ -118,6 +118,7 @@ > sc->an_gone = 1; > bus_teardown_intr(dev, sc->irq_res, sc->irq_handle); > an_release_resources(dev); > + mtx_destroy(&sc->an_mtx); > return (0); > } Take care, --Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 10:43: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id AED1637B40E for ; Sun, 19 Aug 2001 10:42:59 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.5/8.11.5) with ESMTP id f7JHgjI01843; Sun, 19 Aug 2001 18:42:45 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f7JHgiU00866; Sun, 19 Aug 2001 18:42:44 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200108191742.f7JHgiU00866@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-hackers@FreeBSD.org Cc: Brian Somers Subject: IPv6 DAD avoidance Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Aug 2001 18:42:44 +0100 From: Brian Somers 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, Can anybody tell me if it's possbile to tell a given interface not to do DAD ? Specifically, when using the tun device for PPP, PPP negotiates it's own endpoint (link-local) addresses with the peer. However, it doesn't look possible to stop the kernel from doing DAD unless we already have a link-local address assigned to the interface when we IFF_UP it.... Perhaps we could have a new IFF_ flag (say, IFF_NODAD) that could be ioctl()d into the interface's if_flags field and checked in in6_ifattach() ? Thanks for any help.... -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 11:53:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D3A0737B403; Sun, 19 Aug 2001 11:53:18 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7JIrAP45731; Sun, 19 Aug 2001 11:53:10 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Aug 2001 11:53:10 -0700 (PDT) From: Matt Dillon Message-Id: <200108191853.f7JIrAP45731@earth.backplane.com> To: David Greenman Cc: Sergey Babkin , hackers@FreeBSD.ORG, murray@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Recommendation for minor KVM adjustments for the release References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.com> <3B7F0F1E.45A25AC5@bellatlantic.net> <20010819025200.C76779@nexus.root.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 : :>David Greenman wrote: :>> :>> > - I would like to cap the size of the buffer cache at 200MB, :>> > giving us another 70MB or so of KVM which is equivalent to :>> > another 30,000 or so nmbclusters. :>> :>> That also seems like overkill for the vast majority of systems. :> :>But probably not for the large-memory systems (and on the machines :>with small memory the limit will be smaller anyway). Having a :>machine with a few gigs of memory and being able to use only 200MB :>for the buffer cache seems to be quite bad for a general-purpose :>machine. : : Uh, I don't think you understand what this limit is about. It's :essentially the limit on the amount of filesystem directory data that :can be cached. It does not limit the amount of file data that can :be cached - that is only limited by the amount of RAM in the machine. : :-DG : :David Greenman :Co-founder, The FreeBSD Project - http://www.freebsd.org :President, TeraSolutions, Inc. - http://www.terasolutions.com Yes, and the buffer cache determines how much dirty file-backed data (via write() or mmap()) the system is allowed to accumulate before it forces it out, which should probably be the greater concern here. The issue we face in regards to these limitations is simply that the kernel only has 1 GB of KVA space available no matter how much physical ram is in the box. We currently scale a number of things based on physical ram - sendfile() buffer space, buffer cache, swap meta space, kernel malloc area, PV Entry space, and so forth. Machine with large amounts of ram wind up eating up so much KVA that simple tuning elements such as increasing the number of NMBCLUSTERS or increasing 'maxusers' can cause the machine to run out of KVA space during the boot process, resulting in a panic. All I am suggesting here is that we throw in some reasonable limits temporarily (until we can come up with a permanent solution), limits which really only effect machines with greater then 1GB of real memory and which can be overriden by kernel options, in order to avoid common tuning configurations (e.g. large number of NMBCLUSTERS, high 'maxusers' specification) from causing unexpected crashes at boot time. This will give us time to come up with a more permanent solution. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 12: 7:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C8F6937B411; Sun, 19 Aug 2001 12:07:45 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7JJ7cM45828; Sun, 19 Aug 2001 12:07:38 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Aug 2001 12:07:38 -0700 (PDT) From: Matt Dillon Message-Id: <200108191907.f7JJ7cM45828@earth.backplane.com> To: Sergey Babkin Cc: David Greenman , hackers@freebsd.org, murray@freebsd.org, jkh@freebsd.org Subject: Re: Recommendation for minor KVM adjustments for the release References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.com> <3B7F0F1E.45A25AC5@bellatlantic.net> 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 : :David Greenman wrote: :> :> > - I would like to cap the size of the buffer cache at 200MB, :> > giving us another 70MB or so of KVM which is equivalent to :> > another 30,000 or so nmbclusters. :> :> That also seems like overkill for the vast majority of systems. : :But probably not for the large-memory systems (and on the machines :with small memory the limit will be smaller anyway). : :-SB I should also say that even in the Linux and Solaris worlds, systems with > 4GB of ram wind up being very specific-use systems. Typically such systems are used almost solely to run large databases. For example, so something like Oracle can manage a multi-gigabyte cache. These applications do not actually require the memory to be swap-backed, or file-backed, or really managed at all. In FreeBSD land the use-case would simply be our physical-backed-shared- memory feature. We could implement the 8-byte MMU extensions in the PMAP code as a kernrel option to be able to access ram > 4GB without having to change anything else in the kernel (not even vm_page_t or the pmap supporting structures) *IF* we only use the ram > 4GB in physical-backed SysV shared memory mappings. This would actually cover 99% of the needs of people who need to run systems with this much ram. There are lots of issues on IA32 in regards to memory > 4GB... for example, many PCI cards cannot DMA beyond 4GB. We would avoid these issues as well by only using the memory as physical backing store for SysV shared memory segments. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 12: 9: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 2CEE937B411; Sun, 19 Aug 2001 12:09:01 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7JJ8t445840; Sun, 19 Aug 2001 12:08:55 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Aug 2001 12:08:55 -0700 (PDT) From: Matt Dillon Message-Id: <200108191908.f7JJ8t445840@earth.backplane.com> To: David Greenman Cc: hackers@freebsd.org, murray@freebsd.org, jkh@freebsd.org Subject: Re: Recommendation for minor KVM adjustments for the release References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.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 : :> There are two things I would like to commit for the release: :> :> - I would like to cap the SWAPMETA zone reservation to 70MB, :> which allows us to manage a maximum of 29GB worth of swapped :> out data. :> :> This is plenty and saves us 94MB of KVM which is roughly :> equivalent to 30,000 nmbclusters/mbufs. : : It's seems really hard to justify even that much SWAPMETA. A more :reasonable amount would be more like 20MB. : :> - I would like to cap the size of the buffer cache at 200MB, :> giving us another 70MB or so of KVM which is equivalent to :> another 30,000 or so nmbclusters. : : That also seems like overkill for the vast majority of systems. : : :-DG : :David Greenman It's not a 1:1 mapping. There is some sparseness to the way SWAPMETA structures are used so 29GB worth of swap-meta supported VM may wind up only being 15GB of actually-swapped-out-dat in reallity. It depends very heavily on the applications being run. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 13:14: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from lists.unixathome.org (lists.unixathome.org [210.48.103.158]) by hub.freebsd.org (Postfix) with ESMTP id 921C637B408 for ; Sun, 19 Aug 2001 13:14:01 -0700 (PDT) (envelope-from dan@lists.unixathome.org) Received: from wocker (lists.unixathome.org [210.48.103.158]) by lists.unixathome.org (8.11.1/8.11.1) with ESMTP id f7JKDu026602 for ; Mon, 20 Aug 2001 08:13:57 +1200 (NZST) (envelope-from dan@lists.unixathome.org) From: "Dan Langille" Organization: novice in training To: FreeBSD-hackers@FreeBSD.org Date: Sun, 19 Aug 2001 16:13:54 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ld -X <== important or not? Reply-To: dan@langille.org Message-ID: <3B7FE5C2.18273.16C3288@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) 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 How important is the -X option on ld? -X Delete all temporary local symbols. For most tar- gets, this is all local symbols whose names begin with `L'. I ask because I'm porting something to Solaris and it seems rather odd that the solaris ld doesn't have this option. cheers -- Dan Langille - DVL Software Limited FreshPorts - http://freshports.org/ - the place for ports To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 13:47: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C25F237B414; Sun, 19 Aug 2001 13:46:47 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7JKkkA46377; Sun, 19 Aug 2001 13:46:46 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Aug 2001 13:46:46 -0700 (PDT) From: Matt Dillon Message-Id: <200108192046.f7JKkkA46377@earth.backplane.com> To: , , Cc: Leo Bicknell , Peter Wemm Subject: Proposed patch (-stable) for minor KVM adjustments for the release 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 Here is my proposed patch. It adds to options (overrides) to the kernel config, two boot-time tunables for same, and sets reasonable defaults. I also changed the default auto-sizing calculation for swap-meta from 32x physical pages to 16x physical pages on top of it being capped. I only made a small change there since we cannot really afford to run out of swap-meta structures (the system will probably lockup if we do). This patch is against -stable. I will commit it to -current today and await the release-engineers permission to MFC it to -stable for the release. I did some simple testing under -stable, including bumping up maxusers and NMBCLUSTERS. -Matt Index: conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.191.2.35 diff -u -r1.191.2.35 options --- conf/options 2001/08/03 00:47:27 1.191.2.35 +++ conf/options 2001/08/19 20:00:29 @@ -163,6 +163,8 @@ NBUF opt_param.h NMBCLUSTERS opt_param.h NSFBUFS opt_param.h +VM_BCACHE_SIZE_MAX opt_param.h +VM_SWZONE_SIZE_MAX opt_param.h MAXUSERS # Generic SCSI options. Index: i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v retrieving revision 1.749.2.77 diff -u -r1.749.2.77 LINT --- i386/conf/LINT 2001/08/15 01:23:49 1.749.2.77 +++ i386/conf/LINT 2001/08/19 20:27:02 @@ -2315,7 +2315,44 @@ # options NSFBUFS=1024 +# Set the size of the buffer cache KVM reservation, in buffers. This is +# scaled by approximately 16384 bytes. The system will auto-size the buffer +# cache if this option is not specified or set to 0. # +options NBUF=512 + +# Set the size of the mbuf KVM reservation, in clusters. This is scaled +# by approximately 2048 bytes. The system will auto-size the mbuf area +# if this options is not specified or set to 0. +# +options NMBCLUSTERS=1024 + +# Tune the kernel malloc area parameters. VM_KMEM_SIZE represents the +# minimum, in bytes, and is typically (12*1024*1024) (12MB). +# VM_KMEM_SIZE_MAX represents the maximum, typically 200 megabytes. +# VM_KMEM_SIZE_SCALE can be set to adjust the auto-tuning factor, which +# typically defaults to 4 (kernel malloc area size is physical memory +# divided by the scale factor). +# +options VM_KMEM_SIZE="(10*1024*1024)" +options VM_KMEM_SIZE_MAX="(100*1024*1024)" +options VM_KMEM_SIZE_SCALE="4" + +# Tune the buffer cache maximum KVA reservation, in bytes. The maximum is +# usually capped at 200 MB, effecting machines with > 1GB of ram. Note +# that the buffer cache only really governs write buffering and disk block +# translations. The VM page cache is our primary disk cache and is not +# effected by the size of the buffer cache. +# +options VM_BCACHE_SIZE_MAX="(100*1024*1024)" + +# Tune the swap zone KVA reservation, in bytes. The default is typically +# 70 MB, giving the system the ability to manage a maximum of 28GB worth +# of swapped out data. +# +options VM_SWZONE_SIZE_MAX="(50*1024*1024)" + +# # Enable extra debugging code for locks. This stores the filename and # line of whatever acquired the lock in the lock itself, and change a # number of function calls to pass around the relevant data. This is @@ -2500,9 +2537,7 @@ options KEY options LOCKF_DEBUG options LOUTB -options NBUF=512 options NETATALKDEBUG -options NMBCLUSTERS=1024 #options OLTR_NO_BULLSEYE_MAC #options OLTR_NO_HAWKEYE_MAC #options OLTR_NO_TMS_MAC @@ -2521,7 +2556,5 @@ options SPX_HACK options TIMER_FREQ="((14318182+6)/12)" options VFS_BIO_DEBUG -options VM_KMEM_SIZE -options VM_KMEM_SIZE_MAX -options VM_KMEM_SIZE_SCALE options XBONEHACK + Index: i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.385.2.15 diff -u -r1.385.2.15 machdep.c --- i386/i386/machdep.c 2001/07/30 23:27:59 1.385.2.15 +++ i386/i386/machdep.c 2001/08/19 20:36:19 @@ -320,7 +320,9 @@ * The nominal buffer size (and minimum KVA allocation) is BKVASIZE. * For the first 64MB of ram nominally allocate sufficient buffers to * cover 1/4 of our ram. Beyond the first 64MB allocate additional - * buffers to cover 1/20 of our ram over 64MB. + * buffers to cover 1/20 of our ram over 64MB. When auto-sizing + * the buffer cache we limit the eventual kva reservation to + * maxbcache bytes. * * factor represents the 1/4 x ram conversion. */ @@ -332,6 +334,8 @@ nbuf += min((physmem - 1024) / factor, 16384 / factor); if (physmem > 16384) nbuf += (physmem - 16384) * 2 / (factor * 5); + if (maxbcache && nbuf > maxbcache / BKVASIZE) + nbuf = maxbcache / BKVASIZE; } /* Index: i386/include/param.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/param.h,v retrieving revision 1.54.2.4 diff -u -r1.54.2.4 param.h --- i386/include/param.h 2000/12/29 10:59:18 1.54.2.4 +++ i386/include/param.h 2001/08/19 20:07:08 @@ -113,6 +113,22 @@ #define UPAGES 2 /* pages of u-area */ /* + * Ceiling on amount of swblock kva space. + */ +#ifndef VM_SWZONE_SIZE_MAX +#define VM_SWZONE_SIZE_MAX (70 * 1024 * 1024) +#endif + +/* + * Ceiling on size of buffer cache (really only effects write queueing, + * the VM page cache is not effected). + */ +#ifndef VM_BCACHE_SIZE_MAX +#define VM_BCACHE_SIZE_MAX (200 * 1024 * 1024) +#endif + + +/* * Constants related to network buffer management. * MCLBYTES must be no larger than CLBYTES (the software page size), and, * on machines that exchange pages of input or output buffers with mbuf Index: kern/subr_param.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_param.c,v retrieving revision 1.42.2.1 diff -u -r1.42.2.1 subr_param.c --- kern/subr_param.c 2001/07/30 23:28:00 1.42.2.1 +++ kern/subr_param.c 2001/08/19 20:04:05 @@ -76,6 +76,8 @@ int mbuf_wait = 32; /* mbuf sleep time in ticks */ int nbuf; int nswbuf; +int maxswzone; /* max swmeta KVA storage */ +int maxbcache; /* max buffer cache KVA storage */ /* maximum # of sf_bufs (sendfile(2) zero-copy virtual buffers) */ int nsfbufs; @@ -115,6 +117,10 @@ TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); nbuf = NBUF; TUNABLE_INT_FETCH("kern.nbuf", &nbuf); + maxswzone = VM_SWZONE_SIZE_MAX; + TUNABLE_INT_FETCH("kern.maxswzone", &maxswzone); + maxbcache = VM_BCACHE_SIZE_MAX; + TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache); ncallout = 16 + maxproc + maxfiles; TUNABLE_INT_FETCH("kern.ncallout", &ncallout); } Index: sys/buf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/buf.h,v retrieving revision 1.88.2.4 diff -u -r1.88.2.4 buf.h --- sys/buf.h 2001/06/03 05:00:10 1.88.2.4 +++ sys/buf.h 2001/08/19 19:54:02 @@ -455,6 +455,8 @@ #ifdef _KERNEL extern int nbuf; /* The number of buffer headers */ +extern int maxswzone; /* Max KVA for swap structures */ +extern int maxbcache; /* Max KVA for buffer cache */ extern int runningbufspace; extern int buf_maxio; /* nominal maximum I/O for buffer */ extern struct buf *buf; /* The buffer headers. */ Index: vm/swap_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.130.2.8 diff -u -r1.130.2.8 swap_pager.c --- vm/swap_pager.c 2001/03/24 20:28:24 1.130.2.8 +++ vm/swap_pager.c 2001/08/19 19:47:19 @@ -300,10 +300,12 @@ /* * Initialize our zone. Right now I'm just guessing on the number * we need based on the number of pages in the system. Each swblock - * can hold 16 pages, so this is probably overkill. + * can hold 16 pages, so this is probably overkill. This reservation + * is typically limited to around 70MB by default. */ - - n = cnt.v_page_count * 2; + n = cnt.v_page_count; + if (maxswzone && n > maxswzone / sizeof(struct swblock)) + n = maxswzone / sizeof(struct swblock); swap_zone = zinit( "SWAPMETA", To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 13:49:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 41A5137B40C; Sun, 19 Aug 2001 13:49:07 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from 1-083.ctame701-1.telepar.net.br (1-083.ctame701-1.telepar.net.br [200.181.137.83]) by netbank.com.br (Postfix) with ESMTP id 7A22946803; Sun, 19 Aug 2001 17:47:58 -0300 (BRST) Received: from localhost ([IPv6:::ffff:127.0.0.1]:36022 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Sun, 19 Aug 2001 17:48:47 -0300 Date: Sun, 19 Aug 2001 17:48:41 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Matt Dillon Cc: Sergey Babkin , David Greenman , , , Subject: Re: Recommendation for minor KVM adjustments for the release In-Reply-To: <200108191907.f7JJ7cM45828@earth.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.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 On Sun, 19 Aug 2001, Matt Dillon wrote: > In FreeBSD land the use-case would simply be our physical-backed-shared- > memory feature. We could implement the 8-byte MMU extensions in the > PMAP code as a kernrel option to be able to access ram > 4GB without > having to change anything else in the kernel (not even vm_page_t or > the pmap supporting structures) *IF* we only use the ram > 4GB in > physical-backed SysV shared memory mappings. Actually, using it for normal process anonymous memory and file cache is pretty easy. If FreeBSD still has the 16MB ISA bounce buffer code working, there is little reason why the same kind of bounce buffer setup couldn't be done for 32-bit PCI DMA. In Linux this is hidden in the block IO layer, neither the VM or the disk device drivers have to know about it. regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to aardvark@nl.linux.org (spam digging piggy) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 13:50:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id CAE3D37B411; Sun, 19 Aug 2001 13:50:14 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from 1-083.ctame701-1.telepar.net.br (1-083.ctame701-1.telepar.net.br [200.181.137.83]) by netbank.com.br (Postfix) with ESMTP id 95C5A46804; Sun, 19 Aug 2001 17:49:07 -0300 (BRST) Received: from localhost ([IPv6:::ffff:127.0.0.1]:36790 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Sun, 19 Aug 2001 17:50:09 -0300 Date: Sun, 19 Aug 2001 17:50:08 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Matt Dillon Cc: David Greenman , Sergey Babkin , , , Subject: Re: Recommendation for minor KVM adjustments for the release In-Reply-To: <200108191853.f7JIrAP45731@earth.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.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 On Sun, 19 Aug 2001, Matt Dillon wrote: > : Uh, I don't think you understand what this limit is about. It's > :essentially the limit on the amount of filesystem directory data that > :can be cached. It does not limit the amount of file data that can > :be cached - that is only limited by the amount of RAM in the machine. > Yes, and the buffer cache determines how much dirty file-backed data > (via write() or mmap()) the system is allowed to accumulate before > it forces it out, which should probably be the greater concern here. How hard would it be to allow dirty data in the file cache, without buffer mappings ? regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to aardvark@nl.linux.org (spam digging piggy) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 13:53:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sirius.pc.cis.udel.edu (sirius.pc.cis.udel.edu [128.175.202.57]) by hub.freebsd.org (Postfix) with ESMTP id E54B837B411; Sun, 19 Aug 2001 13:53:53 -0700 (PDT) (envelope-from jain@sirius.pc.cis.udel.edu) Received: (from jain@localhost) by sirius.pc.cis.udel.edu (8.11.3/8.11.3) id f7JKnZZ32965; Sun, 19 Aug 2001 16:49:35 -0400 (EDT) (envelope-from jain) Date: Sun, 19 Aug 2001 16:49:35 -0400 (EDT) From: Manish Jain Message-Id: <200108192049.f7JKnZZ32965@sirius.pc.cis.udel.edu> To: dillon@earth.backplane.com, hackers@FreeBSD.ORG, jkh@FreeBSD.ORG, murray@FreeBSD.ORG Subject: Re: Proposed patch (-stable) for minor KVM adjustments for the release Cc: bicknell@ufp.org, peter@wemm.org In-Reply-To: <200108192046.f7JKkkA46377@earth.backplane.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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 13:54:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from digitaldaemon.com (digitaldaemon.com [63.105.9.34]) by hub.freebsd.org (Postfix) with SMTP id 1033037B408 for ; Sun, 19 Aug 2001 13:53:53 -0700 (PDT) (envelope-from jan@digitaldaemon.com) Received: (qmail 82840 invoked from network); 19 Aug 2001 20:51:31 -0000 Received: from unknown (HELO digitaldaemon.com) (192.168.0.73) by digitaldaemon.com with SMTP; 19 Aug 2001 20:51:31 -0000 Message-ID: <3B8026CC.9090805@digitaldaemon.com> Date: Sun, 19 Aug 2001 16:51:24 -0400 From: Jan Knepper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: FreeBSD Hackers Subject: [Fwd: Re: slashdotted: /kernel: xl0: no memory for rx list -- packet dropped!] Content-Type: multipart/alternative; boundary="------------060100050103050904050209" 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 --------------060100050103050904050209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! Does anyone here know what to do about this? Thanks! Jan -------- Original Message -------- From: - Sat Aug 18 12:19:58 2001 X-UIDL: 998151141.23696.digitaldaemon.com,S=3760 X-Mozilla-Status: 0013 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: jan@digitaldaemon.com Received: (qmail 23693 invoked from network); 18 Aug 2001 16:12:20 -0000 Received: from unknown (HELO sm4.texas.rr.com) (root@24.93.35.211) by digitaldaemon.com with SMTP; 18 Aug 2001 16:12:20 -0000 Received: from [192.168.0.138] (cs6668179-144.austin.rr.com [66.68.179.144]) by sm4.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f7IGE8KE018133; Sat, 18 Aug 2001 11:14:08 -0500 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 18 Aug 2001 11:14:12 -0500 Subject: Re: slashdotted: /kernel: xl0: no memory for rx list -- packet dropped! From: "Michael C. Wu" To: Jan Knepper , FreeBSD ISP Message-ID: In-Reply-To: <3B7E9205.7010604@digitaldaemon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit on 08/18/2001 11:04 AM, Jan Knepper at jan@digitaldaemon.com wrote: > Last Thursday one of the sites I host got slashdotted > (http://www.slashdot.com/) and amazingly FreeBSD 4.3 on PIII 600 Mhz > with 128 MB RAM took the load gracefully. I.e. until around 5 PM EST > when I got messages like: This should a good enough system. > /kernel: xl0: no memory for rx list -- packet dropped! > > at the console... > > So what I did is, I terminated some of the daemon's that were not really > used as a couple of httpd server, etc. This seemed to solve the problem, > however... When I run a netstat -na right now I get the impression that > there is still some garbadge in memory from this experience: > > As: > tcp4 0 15360 63.105.9.61.20 217.80.179.220.2822 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.219.43.81.2591 LAST_ACK > tcp4 0 15360 63.105.9.61.20 200.11.220.5.2535 LAST_ACK > tcp4 0 15360 63.105.9.61.20 200.11.220.5.1736 LAST_ACK > tcp4 0 15360 63.105.9.61.20 200.11.220.5.1735 LAST_ACK > tcp4 0 15360 63.105.9.61.20 202.133.131.44.3651 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.4486 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.4338 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.3452 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.3449 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.1825 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.2922 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.2390 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.2310 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.1598 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.1597 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.1556 LAST_ACK > tcp4 0 15360 63.105.9.61.20 193.124.148.213.1553 LAST_ACK > tcp4 0 15360 63.105.9.61.20 203.195.181.4.1440 LAST_ACK > > I am sure this has been in there the last at least 24 hours and I can > see nothing is happening. I suspect that this is because of the no > memory for rx list, but I am not quite sure. I was kinda a cool feeling > though that FreeBSD didn't give up, but still runs!!! I think you might have been attacked by a well-known attack, simply named the LAST_ACK attack. It puts our TCP state machine into whack by not sending the proper TCP states. There is no way around it. > Is there anyway to clean this up without having to reboot the system? I don't know. :) -- keichiii@iteration.net --------------060100050103050904050209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi!

Does anyone here know what to do about this?

Thanks!
Jan



-------- Original Message --------
From: - Sat Aug 18 12:19:58 2001
X-UIDL: 998151141.23696.digitaldaemon.com,S=3760
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <keichii@iteration.net>
Delivered-To: jan@digitaldaemon.com
Received: (qmail 23693 invoked from network); 18 Aug 2001 16:12:20 -0000
Received: from unknown (HELO sm4.texas.rr.com) (root@24.93.35.211) by digitaldaemon.com with SMTP; 18 Aug 2001 16:12:20 -0000
Received: from [192.168.0.138] (cs6668179-144.austin.rr.com [66.68.179.144]) by sm4.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f7IGE8KE018133; Sat, 18 Aug 2001 11:14:08 -0500
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022
Date: Sat, 18 Aug 2001 11:14:12 -0500
Subject: Re: slashdotted: /kernel: xl0: no memory for rx list -- packet dropped!
From: "Michael C. Wu" <keichii@iteration.net>
To: Jan Knepper <jan@digitaldaemon.com>, FreeBSD ISP <FreeBSD-ISP@freebsd.org>
Message-ID: <B7A3FE84.F61%keichii@iteration.net>
In-Reply-To: <3B7E9205.7010604@digitaldaemon.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit 


on 08/18/2001 11:04 AM, Jan Knepper at jan@digitaldaemon.com wrote:
> Last Thursday one of the sites I host got slashdotted
> (http://www.slashdot.com/) and amazingly FreeBSD 4.3 on PIII 600 Mhz
> with 128 MB RAM took the load gracefully. I.e. until around 5 PM EST
> when I got messages like:

This should a good enough system.
 
> /kernel: xl0: no memory for rx list -- packet dropped!
> 
> at the console...
> 
> So what I did is, I terminated some of the daemon's that were not really
> used as a couple of httpd server, etc. This seemed to solve the problem,
> however... When I run a netstat -na right now I get the impression that
> there is still some garbadge in memory from this experience:
> 
> As:
> tcp4       0  15360  63.105.9.61.20         217.80.179.220.2822    LAST_ACK
> t
cp4       0  15360  63.105.9.61.20         193.219.43.81.2591     LAST_ACK
> tcp4       0  15360  63.105.9.61.20         200.11.220.5.2535      LAST_ACK
> tcp4       0  15360  63.105.9.61.20         200.11.220.5.1736      LAST_ACK
> tcp4       0  15360  63.105.9.61.20         200.11.220.5.1735      LAST_ACK
> tcp4       0  15360  63.105.9.61.20         202.133.131.44.3651    LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.4486   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.4338   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.3452   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.3449   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.1825   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.2922   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.2390   LAST_ACK
> tcp4       0  15360
  63.105.9.61.20         193.124.148.213.2310   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.1598   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.1597   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.1556   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         193.124.148.213.1553   LAST_ACK
> tcp4       0  15360  63.105.9.61.20         203.195.181.4.1440     LAST_ACK
> 
> I am sure this has been in there the last at least 24 hours and I can
> see nothing is happening. I suspect that this is because of the no
> memory for rx list, but I am not quite sure. I was kinda a cool feeling
> though that FreeBSD didn't give up, but still runs!!!

I think you might have been attacked by a well-known attack, simply named
the LAST_ACK attack.  It puts our TCP state machine into whack by not
sending the proper TCP states.  There is no way around it.
 
> Is there anyway to clean thi
s up without having to reboot the system?

I don't know. :)
-- 
keichiii@iteration.net
--------------060100050103050904050209-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 14:55:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from m44.spnet.com (m44.spnet.com [207.181.251.44]) by hub.freebsd.org (Postfix) with ESMTP id 0F1DD37B405 for ; Sun, 19 Aug 2001 14:55:04 -0700 (PDT) (envelope-from elh_fbsd@spnet.com) Received: from spnet.com (localhost.spnet [127.0.0.1]) by m44.spnet.com (8.11.5/8.11.4) with ESMTP id f7JLsxh17630; Sun, 19 Aug 2001 14:54:59 -0700 (PDT) (envelope-from elh_fbsd@spnet.com) Message-Id: <200108192154.f7JLsxh17630@m44.spnet.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: hackers@freebsd.org Cc: elh@spnet.com Subject: 4.4-20010815-RC1 GENERIC kernel build fails Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Aug 2001 14:54:59 -0700 From: Ed Hudson 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 maybe this is old news, or maybe it is just me. just yestderday this machine ran netbsd fine, and a few days ago ran 4.4-PRERELEASE0 just fine, including kernel builds. -elh i just did a version install of 4.4-20010815-RC1, and a build of the GENERIC kernel fails (during the make depend operation): uname -a: FreeBSD m6.spnet 4.4-20010815-RC1 FreeBSD 4.4-20010815-RC1 #0: Thu Aug 16 06:35:35 GMT 2001 murray@scrub.lab.nuxi.com:/usr/src/sys/compile/GENERIC i386 pstat -s: Device 1K-blocks Used Avail Capacity Type /dev/ad4s2b 1048448 0 1048448 0% Interleaved make depend: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contrib/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/genassym.c sh ../../kern/genassym.sh genassym.o > assym.s perl5 ../../kern/vnode_if.pl -h ../../kern/vnode_if.src make -f ../../dev/aic7xxx/aicasm/Makefile MAKESRCPATH=../../dev/aic7xxx/aicasm Warning: Object directory not changed from original /usr/src/sys/compile/GENERIC yacc -d ../../dev/aic7xxx/aicasm/aicasm_gram.y mv y.tab.c aicasm_gram.c cc -O -pipe -I/usr/include -I. -c aicasm_gram.c lex -t ../../dev/aic7xxx/aicasm/aicasm_scan.l > aicasm_scan.c cc -O -pipe -I/usr/include -I. -c aicasm_scan.c cc -O -pipe -I/usr/include -I. -c ../../dev/aic7xxx/aicasm/aicasm.c cc -O -pipe -I/usr/include -I. -c ../../dev/aic7xxx/aicasm/aicasm_symbol.c cc -O -pipe -I/usr/include -I. -o aicasm aicasm_gram.o aicasm_scan.o aicasm.o aicasm_symbol.o -ll cc: Internal compiler error: program ld got fatal signal 11 *** Error code 1 Stop in /usr/src/sys/compile/GENERIC. *** Error code 1 Stop in /usr/src/sys/compile/GENERIC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 17: 6:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A5BEA37B407; Sun, 19 Aug 2001 17:06:48 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7K06VK47176; Sun, 19 Aug 2001 17:06:31 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Aug 2001 17:06:31 -0700 (PDT) From: Matt Dillon Message-Id: <200108200006.f7K06VK47176@earth.backplane.com> To: Rik van Riel Cc: David Greenman , Sergey Babkin , , , Subject: Re: Recommendation for minor KVM adjustments for the release 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 :> Yes, and the buffer cache determines how much dirty file-backed data :> (via write() or mmap()) the system is allowed to accumulate before :> it forces it out, which should probably be the greater concern here. : :How hard would it be to allow dirty data in the file :cache, without buffer mappings ? : :regards, : :Rik This is already supported via MAP_NOSYNC. The problem is that the dirty data is not tracked under light memory loads (tracking dirty data is a function of the buffer cache), so unless something forces the page out or fsync()s the file explicitly, the dirty data might not be written out for days. It might look good in a benchmark, but it would play havoc on system stability in the event of a crash. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 18: 2:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id C95E737B40C for ; Sun, 19 Aug 2001 18:02:28 -0700 (PDT) (envelope-from ticso@mail.cicely.de) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f7K12PA02281; Mon, 20 Aug 2001 03:02:26 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f7K12Vg02923; Mon, 20 Aug 2001 03:02:31 +0200 (CEST) Date: Mon, 20 Aug 2001 03:02:30 +0200 From: Bernd Walter To: Jan Knepper Cc: FreeBSD Hackers Subject: Re: [Fwd: Re: slashdotted: /kernel: xl0: no memory for rx list -- packet dropped!] Message-ID: <20010820030230.B2719@cicely20.cicely.de> References: <3B8026CC.9090805@digitaldaemon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B8026CC.9090805@digitaldaemon.com>; from jan@digitaldaemon.com on Sun, Aug 19, 2001 at 04:51:24PM -0400 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc 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, Aug 19, 2001 at 04:51:24PM -0400, Jan Knepper wrote: > Hi! > > Does anyone here know what to do about this? Read the manpage for the xl driver: xl%d: no memory for rx list The driver failed to allocate an mbuf for the receiver ring. Increase the nmbclusters or decrease the mbuf load. You can check the current values with netstat -m. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 18:11:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-7.dsl.lsan03.pacbell.net [63.207.60.7]) by hub.freebsd.org (Postfix) with ESMTP id 923AB37B406 for ; Sun, 19 Aug 2001 18:11:33 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F344166D37; Sun, 19 Aug 2001 18:11:32 -0700 (PDT) Date: Sun, 19 Aug 2001 18:11:32 -0700 From: Kris Kennaway To: Ed Hudson Cc: hackers@freebsd.org, elh@spnet.com Subject: Re: 4.4-20010815-RC1 GENERIC kernel build fails Message-ID: <20010819181132.B1811@xor.obsecurity.org> References: <200108192154.f7JLsxh17630@m44.spnet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="yNb1oOkm5a9FJOVX" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108192154.f7JLsxh17630@m44.spnet.com>; from elh_fbsd@spnet.com on Sun, Aug 19, 2001 at 02:54:59PM -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 --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 19, 2001 at 02:54:59PM -0700, Ed Hudson wrote: > cc: Internal compiler error: program ld got fatal signal 11 > *** Error code 1 >=20 > Stop in /usr/src/sys/compile/GENERIC. > *** Error code 1 >=20 > Stop in /usr/src/sys/compile/GENERIC. See the FAQ entry about sig11's. Kris --yNb1oOkm5a9FJOVX 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 iD8DBQE7gGPEWry0BWjoQKURAl+mAJ45W44ThMbvgvO73xLVikGfcxTsuACgiD6q D4a5OTwIUZq+chN2iBzm5WQ= =gSDW -----END PGP SIGNATURE----- --yNb1oOkm5a9FJOVX-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 18:44:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from digitaldaemon.com (digitaldaemon.com [63.105.9.34]) by hub.freebsd.org (Postfix) with SMTP id 19E5A37B415 for ; Sun, 19 Aug 2001 18:44:48 -0700 (PDT) (envelope-from jan@digitaldaemon.com) Received: (qmail 92602 invoked from network); 20 Aug 2001 01:42:31 -0000 Received: from unknown (HELO digitaldaemon.com) (192.168.0.73) by digitaldaemon.com with SMTP; 20 Aug 2001 01:42:31 -0000 Message-ID: <3B806A8A.3040903@digitaldaemon.com> Date: Sun, 19 Aug 2001 21:40:26 -0400 From: Jan Knepper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bernd Walter Cc: FreeBSD Hackers Subject: Re: [Fwd: Re: slashdotted: /kernel: xl0: no memory for rx list -- packet dropped!] References: <3B8026CC.9090805@digitaldaemon.com> <20010820030230.B2719@cicely20.cicely.de> Content-Type: multipart/alternative; boundary="------------040204070806030009070709" 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 --------------040204070806030009070709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I figured that much. What I am looking for is a way to clear the connections still showing LAST_ASK Jan Bernd Walter wrote: >On Sun, Aug 19, 2001 at 04:51:24PM -0400, Jan Knepper wrote: > >>Hi! >> >>Does anyone here know what to do about this? >> > >Read the manpage for the xl driver: > xl%d: no memory for rx list The driver failed to allocate an mbuf for > the receiver ring. > >Increase the nmbclusters or decrease the mbuf load. >You can check the current values with netstat -m. > --------------040204070806030009070709 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I figured that much.
What I am looking for is a way to clear the connections still showing  LAST_ASK

Jan



Bernd Walter wrote:
On Sun, Aug 19, 2001 at 04:51:24PM -0400, Jan Knepper wrote:
Hi!

Does anyone here know what to do about this?

Read the manpage for the xl driver:
     xl%d: no memory for rx list  The driver failed to allocate an mbuf for
     the receiver ring.

Increase the nmbclusters or decrease the mbuf load.
You can check the current values with netstat -m.


--------------040204070806030009070709-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 19:40:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from best.llama.com (llama.com [63.194.69.194]) by hub.freebsd.org (Postfix) with ESMTP id CA52D37B411; Sun, 19 Aug 2001 19:40:06 -0700 (PDT) (envelope-from the@best.llama.com) Received: (from the@localhost) by best.llama.com (8.9.3/8.9.3) id TAA36670; Sun, 19 Aug 2001 19:40:06 -0700 (PDT) (envelope-from the) Date: Sun, 19 Aug 2001 19:40:06 -0700 From: Sam Habash To: Jonathan Chen Cc: mobile@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kern/24854: NEWCARD support for aironet driver an(4) Message-ID: <20010819194006.A36256@llama.com> References: <20010817011103.A25841@llama.com> <20010818110728.A20719@enterprise.spock.org> <20010818092654.C28694@llama.com> <20010818124503.A26350@enterprise.spock.org> <20010818212011.A33879@llama.com> <20010819091452.A86632@enterprise.spock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010819091452.A86632@enterprise.spock.org>; from jon@FreeBSD.ORG on Sun, Aug 19, 2001 at 09:14:52AM -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 Sun, Aug 19, 2001 at 09:14:52AM -0400, Jonathan Chen wrote: > Are you sure there is no panic while in X? Your X server might have > futzed with the video card so you might not actually see the panic. If you > can try to reproduce this in text mode, then the panic message as well as a > traceback would be a very good start. Hmmm...what I saw appeared to be a spontaneous reboot. Forgot to mention that earlier. > But before you do that, I believe I may have found a fix for a possible > panic situation. This panic occurs in witness_destroy as a supervisor read > page not present error (I presume while trying to dereference lock). This > panic can be easily reproduced by running dhclient an0, removing and > reinserting the card, then killing dhclient. The fix appears to be > shockingly simple: > > diff -u -r1.8 if_an_pccard.c > --- sys/dev/an/if_an_pccard.c 2001/05/26 09:26:58 1.8 > +++ sys/dev/an/if_an_pccard.c 2001/08/19 12:57:14 > @@ -118,6 +118,7 @@ > sc->an_gone = 1; > bus_teardown_intr(dev, sc->irq_res, sc->irq_handle); > an_release_resources(dev); > + mtx_destroy(&sc->an_mtx); > return (0); > } > Here's the panic and traceback (typed by hand, haven't set up serial console for this). This is BEFORE applying the patch to if_an_pccard.c, as with the patch, no panic occurs. Cool. Fatal trap 12: page fault while in kernel mode fault virtual addresss = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc027a577 stack pointer = 0x10:0xcd861d3c frame pointer = 0x10:0xcd861d48 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IPL = 0 current process = 542 (dhclient) kernel : type 12 trap, code=0 Stopped at witness_destroy+0x237: cmpl %esi,0xc(%edx) db> trace witness_destroy(c2577a58,c2577a00,cd861d68,c02acaf4,c2577a58) at witness_destroy +0x237 mtx_destroy(c2577a58,c2577a00,cd861d7c,c02aae8a,c2577a00) at mtx_destory+0x73 bpf_freed(c2577a00,cd8a20a0,cd83db80,cd861da4,c0234e6c) at bpf_freed+0x68 bpfclose)(c2574400,3,2000,cd83db80,c2574400) at bpfclose+0x136 spec_close(cd861dc4,cd861dd8,c02a85d4,cd861dc4,c2511080) at spec_close+0x90 spec_vnoperate(cd861dc4,c2511080,c2511080,c04354a0,cd8a20a0) at spec_vnoperate+0x15 vn_close(cd8a20a0,3,c2572f00,cd83db80,cd861e38) at vn_close+0x40 vn_closefile(c2511080,cd83db80,cd83db80,c2511080,c027ba56) at vn_closefile+0x1f fdrop(c2511080,cd83db80,ffffffff,c2577b50,c027acac) at fdrop+0xaf closef(c2511080,cd83db80) at closef+0x9b fdfree(cd83db80,cd83dce8) at fdfree+0x38 exit1(cd83db80,f,0,cd83db80,ffffbfff) at exit1+0x61d sigexit(cd83db80,f,ffffffff,4,cd83db80) at sigexit+0x2f7 postsig(f) at postsig+0xec userret(cd83db80,cd861a8,51f,1b,80a9aa0) at userret+0x5b6 syscall(bfbf002f,80a002f,bfbf002f,bfbfe174,80a9aa0) at syscall+0x67b syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (81, FreeBSD ELF, getpgrp), eip = 0x8055864, esp = 0xbfbfdcd8, ebp = 0xbfbfdd04 --- --Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 19 22:17:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id AF69937B410 for ; Sun, 19 Aug 2001 22:17:41 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.3+3.4W/8.11.3) with ESMTP/inet id f7K5HQa23337; Mon, 20 Aug 2001 14:17:27 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: brian@Awfulhak.org In-Reply-To: <200108191742.f7JHgiU00866@hak.lan.Awfulhak.org> References: <200108191742.f7JHgiU00866@hak.lan.Awfulhak.org> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) 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: 13 From: Makoto MATSUSHITA To: hackers@freebsd.org Subject: Re: IPv6 DAD avoidance Date: Mon, 20 Aug 2001 14:17:19 +0900 Message-Id: <20010820141719Z.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 brian> Can anybody tell me if it's possbile to tell a given interface brian> not to do DAD ? There is a kernel MIB, 'net.inet6.ip6.dad_count'. See inet6(4) manpage for more detail. However, there is no way to stop DAD for any given interfaces; only we have two choices, 'do DAD to any interfaces' or 'do not DAD to all interfaces'. -- - 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 Mon Aug 20 0:17: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-7.dsl.lsan03.pacbell.net [63.207.60.7]) by hub.freebsd.org (Postfix) with ESMTP id 7779637B413 for ; Mon, 20 Aug 2001 00:16:55 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 03B8B66D15; Mon, 20 Aug 2001 00:16:54 -0700 (PDT) Date: Mon, 20 Aug 2001 00:16:54 -0700 From: Kris Kennaway To: hackers@FreeBSD.org Subject: [PATCH] install -s -s(trip-me-harder) Message-ID: <20010820001654.A32129@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable What do people think about the following patch to install(1) to make it strip additional useless (at runtime - they may be used for debugging purposes) symbols and ELF sections from binaries at install-time, if the '-s' option is used multiple times? This usually saves a few tens of kilobytes per binary. Kris Index: xinstall.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr2/ncvs/src/usr.bin/xinstall/xinstall.c,v retrieving revision 1.38.2.3 diff -u -r1.38.2.3 xinstall.c --- xinstall.c 2001/08/01 06:48:41 1.38.2.3 +++ xinstall.c 2001/08/20 07:13:17 @@ -92,7 +92,7 @@ void install __P((char *, char *, u_long, u_int)); void install_dir __P((char *)); u_long numeric_id __P((char *, char *)); -void strip __P((char *)); +void strip __P((char *, int)); int trymmap __P((int)); void usage __P((void)); =20 @@ -108,6 +108,7 @@ u_int iflags; char *flags, *group, *owner, *to_name; =20 + dostrip =3D 0; iflags =3D 0; group =3D owner =3D NULL; while ((ch =3D getopt(argc, argv, "B:bCcdf:g:Mm:o:pSsv")) !=3D -1) @@ -156,7 +157,7 @@ safecopy =3D 1; break; case 's': - dostrip =3D 1; + dostrip++; break; case 'v': verbose =3D 1; @@ -349,7 +350,7 @@ } =20 if (dostrip) { - strip(tempcopy ? tempfile : to_name); + strip(tempcopy ? tempfile : to_name, dostrip); =20 /* * Re-open our fd on the target, in case we used a strip @@ -696,8 +697,9 @@ * use strip(1) to strip the target file */ void -strip(to_name) +strip(to_name, level) char *to_name; + int level; { int serrno, status; =20 @@ -708,7 +710,12 @@ errno =3D serrno; err(EX_TEMPFAIL, "fork"); case 0: - execlp("strip", "strip", to_name, (char *)NULL); + if (level > 1) + execlp("strip", "strip", "-s", "-R", ".comment", + "-R", ".note", "-N", "gcc2_compiled", + to_name, (char *)NULL); + else + execlp("strip", "strip", to_name, (char *)NULL); err(EX_OSERR, "exec(strip)"); default: if (wait(&status) =3D=3D -1 || status) { --LQksG6bCIzRHxTLp 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 iD8DBQE7gLllWry0BWjoQKURAg2dAKCtt4dPOqlM4nq7kaDI32UePvAsOQCbBrin wkgPf7WRzRn8u9fNGysBao0= =7vkE -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 1:19:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id D512537B410 for ; Mon, 20 Aug 2001 01:19:06 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7K8J5M67698 for ; Mon, 20 Aug 2001 01:19:05 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8AE663811; Mon, 20 Aug 2001 01:19:05 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Kris Kennaway Cc: hackers@FreeBSD.ORG Subject: Re: [PATCH] install -s -s(trip-me-harder) In-Reply-To: <20010820001654.A32129@xor.obsecurity.org> Date: Mon, 20 Aug 2001 01:19:05 -0700 From: Peter Wemm Message-Id: <20010820081905.8AE663811@overcee.netplex.com.au> 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 Kris Kennaway wrote: > + execlp("strip", "strip", "-s", "-R", ".comment", > + "-R", ".note", "-N", "gcc2_compiled", > + to_name, (char *)NULL); Some comments: .note: used in ELF branding. gcc2_compiled: used by gdb I miss the mcs(1) command (manipulate comment section). Specifically, you did a 'mcs -c progname' and it compressed and removed any duplicate comment strings. This was ideal for moving your rcsid strings into from header files. Regarding stripping gcc2_compiled.. strip can only filter symbols from the .symtab and .symstr symbol tables. Since strip already removes both of those sections, the -N gcc2_compiled is useless. strip cannot modify the .dynsym/.dynstr in the PT_LOAD sections, so those will stay regardless. In all, I think this -R gcc2_compiled. is useless unless you're in -X or -D mode (only remove debug symbols etc). gdb uses gcc2_compiled to tune its understanding of the generated code. I suspect the fact that we remove this from the kernel is part of the reason gdb has so much trouble understanding local variables in gdb -k mode. (It doesn't understand trap frames either, but thats another story.) Removing the .note *section* is probably a good idea since it is effectively useless in an executable. The PT_NOTE executable header is unaffected by stripping the leftover .note section contents. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "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 Mon Aug 20 1:24:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-7.dsl.lsan03.pacbell.net [63.207.60.7]) by hub.freebsd.org (Postfix) with ESMTP id 5535337B401 for ; Mon, 20 Aug 2001 01:24:36 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C391466D37; Mon, 20 Aug 2001 01:24:35 -0700 (PDT) Date: Mon, 20 Aug 2001 01:24:35 -0700 From: Kris Kennaway To: Peter Wemm Cc: Kris Kennaway , hackers@FreeBSD.ORG Subject: Re: [PATCH] install -s -s(trip-me-harder) Message-ID: <20010820012435.A35600@xor.obsecurity.org> References: <20010820001654.A32129@xor.obsecurity.org> <20010820081905.8AE663811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010820081905.8AE663811@overcee.netplex.com.au>; from peter@wemm.org on Mon, Aug 20, 2001 at 01:19:05AM -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 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 20, 2001 at 01:19:05AM -0700, Peter Wemm wrote: > Regarding stripping gcc2_compiled.. strip can only filter symbols from > the .symtab and .symstr symbol tables. Since strip already removes both > of those sections, the -N gcc2_compiled is useless. strip cannot modify > the .dynsym/.dynstr in the PT_LOAD sections, so those will stay regardless. > In all, I think this -R gcc2_compiled. is useless unless you're in -X or > -D mode (only remove debug symbols etc). Are you sure this is true? The binaries I've stripped in this way don't seem to contain any reference to the symbol. > gdb uses gcc2_compiled to tune its understanding of the generated code. > I suspect the fact that we remove this from the kernel is part of the reason > gdb has so much trouble understanding local variables in gdb -k mode. > (It doesn't understand trap frames either, but thats another story.) That's why I added it to '-s -s'..if you're stripping symbols like this, you probably don't care about debugging (and this would be documented in the manpage). > Removing the .note *section* is probably a good idea since it is effectively > useless in an executable. The PT_NOTE executable header is unaffected by > stripping the leftover .note section contents. Kris --tKW2IUtsqtDRztdT 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 iD8DBQE7gMlCWry0BWjoQKURAq5MAKCcJ2SIEJj2iPfZIdqfWwd5sNy/MQCdGWxk BIWoVlne5cR3kojpdQQwiJ4= =Rn6c -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 1:56: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 68F0537B406; Mon, 20 Aug 2001 01:55:34 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7K8tYM67829; Mon, 20 Aug 2001 01:55:34 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 271B93905; Mon, 20 Aug 2001 01:55:34 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Matt Dillon Cc: murray@FreeBSD.ORG, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG, Leo Bicknell Subject: Re: Proposed patch (-stable) for minor KVM adjustments for the release In-Reply-To: <200108192046.f7JKkkA46377@earth.backplane.com> Date: Mon, 20 Aug 2001 01:55:34 -0700 From: Peter Wemm Message-Id: <20010820085534.271B93905@overcee.netplex.com.au> 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 Murray/jkh, please do not approve this for MFC until the problems have been fixed. For starters, it breaks all platforms other than the i386. Matt Dillon wrote: > Here is my proposed patch. It adds to options (overrides) to the kernel > config, two boot-time tunables for same, and sets reasonable defaults. > I also changed the default auto-sizing calculation for swap-meta from > 32x physical pages to 16x physical pages on top of it being capped. > I only made a small change there since we cannot really afford to run > out of swap-meta structures (the system will probably lockup if we do). > > This patch is against -stable. I will commit it to -current today and > await the release-engineers permission to MFC it to -stable for the > release. I did some simple testing under -stable, including bumping up > maxusers and NMBCLUSTERS. > > -Matt > > Index: conf/options > =================================================================== > RCS file: /home/ncvs/src/sys/conf/options,v > retrieving revision 1.191.2.35 > diff -u -r1.191.2.35 options > --- conf/options 2001/08/03 00:47:27 1.191.2.35 > +++ conf/options 2001/08/19 20:00:29 > @@ -163,6 +163,8 @@ > NBUF opt_param.h > NMBCLUSTERS opt_param.h > NSFBUFS opt_param.h > +VM_BCACHE_SIZE_MAX opt_param.h > +VM_SWZONE_SIZE_MAX opt_param.h > MAXUSERS > > # Generic SCSI options. > Index: i386/conf/LINT > =================================================================== > RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v > retrieving revision 1.749.2.77 > diff -u -r1.749.2.77 LINT > --- i386/conf/LINT 2001/08/15 01:23:49 1.749.2.77 > +++ i386/conf/LINT 2001/08/19 20:27:02 > @@ -2315,7 +2315,44 @@ > # > options NSFBUFS=1024 > > +# Set the size of the buffer cache KVM reservation, in buffers. This is > +# scaled by approximately 16384 bytes. The system will auto-size the buffer > +# cache if this option is not specified or set to 0. > # > +options NBUF=512 > + > +# Set the size of the mbuf KVM reservation, in clusters. This is scaled > +# by approximately 2048 bytes. The system will auto-size the mbuf area > +# if this options is not specified or set to 0. > +# > +options NMBCLUSTERS=1024 > + > +# Tune the kernel malloc area parameters. VM_KMEM_SIZE represents the > +# minimum, in bytes, and is typically (12*1024*1024) (12MB). > +# VM_KMEM_SIZE_MAX represents the maximum, typically 200 megabytes. > +# VM_KMEM_SIZE_SCALE can be set to adjust the auto-tuning factor, which > +# typically defaults to 4 (kernel malloc area size is physical memory > +# divided by the scale factor). > +# > +options VM_KMEM_SIZE="(10*1024*1024)" > +options VM_KMEM_SIZE_MAX="(100*1024*1024)" > +options VM_KMEM_SIZE_SCALE="4" > + > +# Tune the buffer cache maximum KVA reservation, in bytes. The maximum is > +# usually capped at 200 MB, effecting machines with > 1GB of ram. Note > +# that the buffer cache only really governs write buffering and disk block > +# translations. The VM page cache is our primary disk cache and is not > +# effected by the size of the buffer cache. > +# > +options VM_BCACHE_SIZE_MAX="(100*1024*1024)" > + > +# Tune the swap zone KVA reservation, in bytes. The default is typically > +# 70 MB, giving the system the ability to manage a maximum of 28GB worth > +# of swapped out data. > +# > +options VM_SWZONE_SIZE_MAX="(50*1024*1024)" > + > +# > # Enable extra debugging code for locks. This stores the filename and > # line of whatever acquired the lock in the lock itself, and change a > # number of function calls to pass around the relevant data. This is > @@ -2500,9 +2537,7 @@ > options KEY > options LOCKF_DEBUG > options LOUTB > -options NBUF=512 > options NETATALKDEBUG > -options NMBCLUSTERS=1024 > #options OLTR_NO_BULLSEYE_MAC > #options OLTR_NO_HAWKEYE_MAC > #options OLTR_NO_TMS_MAC > @@ -2521,7 +2556,5 @@ > options SPX_HACK > options TIMER_FREQ="((14318182+6)/12)" > options VFS_BIO_DEBUG > -options VM_KMEM_SIZE > -options VM_KMEM_SIZE_MAX > -options VM_KMEM_SIZE_SCALE > options XBONEHACK > + > Index: i386/i386/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v > retrieving revision 1.385.2.15 > diff -u -r1.385.2.15 machdep.c > --- i386/i386/machdep.c 2001/07/30 23:27:59 1.385.2.15 > +++ i386/i386/machdep.c 2001/08/19 20:36:19 > @@ -320,7 +320,9 @@ > * The nominal buffer size (and minimum KVA allocation) is BKVASIZE. > * For the first 64MB of ram nominally allocate sufficient buffers to > * cover 1/4 of our ram. Beyond the first 64MB allocate additional > - * buffers to cover 1/20 of our ram over 64MB. > + * buffers to cover 1/20 of our ram over 64MB. When auto-sizing > + * the buffer cache we limit the eventual kva reservation to > + * maxbcache bytes. > * > * factor represents the 1/4 x ram conversion. > */ > @@ -332,6 +334,8 @@ > nbuf += min((physmem - 1024) / factor, 16384 / factor); > if (physmem > 16384) > nbuf += (physmem - 16384) * 2 / (factor * 5); > + if (maxbcache && nbuf > maxbcache / BKVASIZE) > + nbuf = maxbcache / BKVASIZE; > } > > /* > Index: i386/include/param.h > =================================================================== > RCS file: /home/ncvs/src/sys/i386/include/param.h,v > retrieving revision 1.54.2.4 > diff -u -r1.54.2.4 param.h > --- i386/include/param.h 2000/12/29 10:59:18 1.54.2.4 > +++ i386/include/param.h 2001/08/19 20:07:08 > @@ -113,6 +113,22 @@ > #define UPAGES 2 /* pages of u-area */ > > /* > + * Ceiling on amount of swblock kva space. > + */ > +#ifndef VM_SWZONE_SIZE_MAX > +#define VM_SWZONE_SIZE_MAX (70 * 1024 * 1024) > +#endif > + > +/* > + * Ceiling on size of buffer cache (really only effects write queueing, > + * the VM page cache is not effected). > + */ > +#ifndef VM_BCACHE_SIZE_MAX > +#define VM_BCACHE_SIZE_MAX (200 * 1024 * 1024) > +#endif > + > + > +/* > * Constants related to network buffer management. > * MCLBYTES must be no larger than CLBYTES (the software page size), and, > * on machines that exchange pages of input or output buffers with mbuf > Index: kern/subr_param.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/subr_param.c,v > retrieving revision 1.42.2.1 > diff -u -r1.42.2.1 subr_param.c > --- kern/subr_param.c 2001/07/30 23:28:00 1.42.2.1 > +++ kern/subr_param.c 2001/08/19 20:04:05 > @@ -76,6 +76,8 @@ > int mbuf_wait = 32; /* mbuf sleep time in ticks */ > int nbuf; > int nswbuf; > +int maxswzone; /* max swmeta KVA storage */ > +int maxbcache; /* max buffer cache KVA storage */ > > /* maximum # of sf_bufs (sendfile(2) zero-copy virtual buffers) */ > int nsfbufs; > @@ -115,6 +117,10 @@ > TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > nbuf = NBUF; > TUNABLE_INT_FETCH("kern.nbuf", &nbuf); > + maxswzone = VM_SWZONE_SIZE_MAX; > + TUNABLE_INT_FETCH("kern.maxswzone", &maxswzone); > + maxbcache = VM_BCACHE_SIZE_MAX; > + TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache); > ncallout = 16 + maxproc + maxfiles; > TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > } > Index: sys/buf.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/buf.h,v > retrieving revision 1.88.2.4 > diff -u -r1.88.2.4 buf.h > --- sys/buf.h 2001/06/03 05:00:10 1.88.2.4 > +++ sys/buf.h 2001/08/19 19:54:02 > @@ -455,6 +455,8 @@ > > #ifdef _KERNEL > extern int nbuf; /* The number of buffer headers */ > +extern int maxswzone; /* Max KVA for swap structures */ > +extern int maxbcache; /* Max KVA for buffer cache */ > extern int runningbufspace; > extern int buf_maxio; /* nominal maximum I/O for buffer */ > extern struct buf *buf; /* The buffer headers. */ > Index: vm/swap_pager.c > =================================================================== > RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v > retrieving revision 1.130.2.8 > diff -u -r1.130.2.8 swap_pager.c > --- vm/swap_pager.c 2001/03/24 20:28:24 1.130.2.8 > +++ vm/swap_pager.c 2001/08/19 19:47:19 > @@ -300,10 +300,12 @@ > /* > * Initialize our zone. Right now I'm just guessing on the number > * we need based on the number of pages in the system. Each swblock > - * can hold 16 pages, so this is probably overkill. > + * can hold 16 pages, so this is probably overkill. This reservation > + * is typically limited to around 70MB by default. > */ > - > - n = cnt.v_page_count * 2; > + n = cnt.v_page_count; > + if (maxswzone && n > maxswzone / sizeof(struct swblock)) > + n = maxswzone / sizeof(struct swblock); > > swap_zone = zinit( > "SWAPMETA", > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "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 Mon Aug 20 2:22:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 9191A37B41B for ; Mon, 20 Aug 2001 02:22:41 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B2DAF81D13; Mon, 20 Aug 2001 04:22:40 -0500 (CDT) Date: Mon, 20 Aug 2001 04:22:40 -0500 From: Alfred Perlstein To: Kris Kennaway Cc: Peter Wemm , hackers@FreeBSD.ORG Subject: Re: [PATCH] install -s -s(trip-me-harder) Message-ID: <20010820042240.B81307@elvis.mu.org> References: <20010820001654.A32129@xor.obsecurity.org> <20010820081905.8AE663811@overcee.netplex.com.au> <20010820012435.A35600@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010820012435.A35600@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Aug 20, 2001 at 01:24:35AM -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 * Kris Kennaway [010820 03:26] wrote: > On Mon, Aug 20, 2001 at 01:19:05AM -0700, Peter Wemm wrote: > > > Regarding stripping gcc2_compiled.. strip can only filter symbols from > > the .symtab and .symstr symbol tables. Since strip already removes both > > of those sections, the -N gcc2_compiled is useless. strip cannot modify > > the .dynsym/.dynstr in the PT_LOAD sections, so those will stay regardless. > > In all, I think this -R gcc2_compiled. is useless unless you're in -X or > > -D mode (only remove debug symbols etc). > > Are you sure this is true? The binaries I've stripped in this way > don't seem to contain any reference to the symbol. Personally I find that doubling of flag to change behavior breaks POLA unless it's the option for 'verbose'. I can imagine a bunch of scripts that might accidentally add flags to existing flags causing breakage. Sort of like if 'cc -g -g' did something odd to the generated debug symbols. Just my opinion though. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 2:22:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 47AC337B41D for ; Mon, 20 Aug 2001 02:22:49 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.5/8.11.5) with ESMTP id f7K9Mbv10052; Mon, 20 Aug 2001 10:22:37 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f7K9MUU78293; Mon, 20 Aug 2001 10:22:30 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200108200922.f7K9MUU78293@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Makoto MATSUSHITA Cc: hackers@freebsd.org, brian@Awfulhak.org, brian@freebsd-services.com Subject: Re: IPv6 DAD avoidance In-Reply-To: Message from Makoto MATSUSHITA of "Mon, 20 Aug 2001 14:17:19 +0900." <20010820141719Z.matusita@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Aug 2001 10:22:30 +0100 From: Brian Somers 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 > > brian> Can anybody tell me if it's possbile to tell a given interface > brian> not to do DAD ? > > There is a kernel MIB, 'net.inet6.ip6.dad_count'. See inet6(4) > manpage for more detail. > > However, there is no way to stop DAD for any given interfaces; only > we have two choices, 'do DAD to any interfaces' or 'do not DAD to all > interfaces'. Would it be worth bringing up the subject of adding an IFF_ flag that can be SIOCSIFFLAGS'd into the interface with the kame team ? Currently, ppp manages to control the link-local address every second time it's run on a given interface... which just looks weird :*I It seems more sane to allow a program to say ``I do my own address discovery''. If you think it's worth bringing up with the kame guys, can you tell me where I should send the mail (which list address) ? Thanks. > -- - > Makoto `MAR' MATSUSHITA -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 4:28: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pelissero.org (dyn69-32.sftm-212-159.plus.net [212.159.32.69]) by hub.freebsd.org (Postfix) with ESMTP id 2C02237B409; Mon, 20 Aug 2001 04:27:41 -0700 (PDT) (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.11.5/8.9.3) id f7KBRPl03252; Mon, 20 Aug 2001 12:27:25 +0100 (BST) (envelope-from wcp) From: "Walter C. Pelissero" Message-ID: <15232.62492.730149.447791@hyde.lpds.sublink.org> Date: Mon, 20 Aug 2001 12:27:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hackers@freebsd.org, net@freebsd.org Subject: 4.4-RC NFS panic X-Mailer: VM 6.90 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP 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 seems my original article didn't get through ] I recently upgraded to 4.4-RC. Now my Vaio panics when I use NFS volumes (as client). The panic is reproducible with a: find /some/NFS/mount/point -type f -exec cat {} \; >/dev/null Sometime I got a "page fault", sometime a "lockmgr: locking against myself" Here is a kgdb session: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". Reading symbols from kernel.debug...done. IdlePTD 3612672 initial pcb at 2bb8a0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x33693d55 fault code = supervisor read, page not present instruction pointer = 0x8:0xc016dbdd stack pointer = 0x10:0xc7834c58 frame pointer = 0x10:0xc7834c64 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 180 (nfsiod) interrupt mask = net trap number = 12 panic: page fault syncing disks... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 done Uptime: 3m58s dumping to dev #ad/0x30001, offset 272736 dump ata0: resetting devices .. done 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at ../../kern/kern_shutdown.c:472 (kgdb) bt #0 dumpsys () at ../../kern/kern_shutdown.c:472 #1 0xc015250f in boot (howto=256) at ../../kern/kern_shutdown.c:312 #2 0xc01528dc in poweroff_wait (junk=0xc027b66c, howto=-1071140465) at ../../kern/kern_shutdown.c:580 #3 0xc023b4b2 in trap_fatal (frame=0xc7834c18, eva=862534997) at ../../i386/i386/trap.c:956 #4 0xc023b185 in trap_pfault (frame=0xc7834c18, usermode=0, eva=862534997) at ../../i386/i386/trap.c:849 #5 0xc023ad6f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 6684672, tf_esi = 862534981, tf_ebp = -947696540, tf_isp = -947696572, tf_ebx = 862534981, tf_edx = 6684672, tf_ecx = -1066162108, tf_eax = 6684672, tf_trapno = 12, tf_err = 0, tf_eip = -1072243747, tf_cs = 8, tf_eflags = 66054, tf_esp = -1066172160, tf_ss = -1066172160}) at ../../i386/i386/trap.c:448 #6 0xc016dbdd in m_freem (m=0x33693d45) at ../../kern/uipc_mbuf.c:618 #7 0xc016dbfc in m_freem (m=0xc0738a00) at ../../kern/uipc_mbuf.c:618 #8 0xc0b59652 in ?? () #9 0xc0b66b92 in ?? () #10 0xc0b3fe37 in ?? () #11 0xc0b606de in ?? () #12 0xc0b5f11b in ?? () #13 0xc023b75d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077936680, tf_esi = 0, tf_ebp = -1077936776, tf_isp = -947695660, tf_ebx = 2, tf_edx = 1, tf_ecx = 19, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 134515664, tf_cs = 31, tf_eflags = 643, tf_esp = -1077936852, tf_ss = 47}) at ../../i386/i386/trap.c:1155 #14 0xc022fae5 in Xint0x80_syscall () #15 0x8048135 in ?? () (kgdb) -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 5:42:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (sentinel.office1.bg [217.75.135.254]) by hub.freebsd.org (Postfix) with SMTP id 9953E37B419 for ; Mon, 20 Aug 2001 05:42:28 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 1033 invoked by uid 1000); 20 Aug 2001 12:40:09 -0000 Date: Mon, 20 Aug 2001 15:40:09 +0300 From: Peter Pentchev To: "Walter C. Pelissero" Cc: hackers@freebsd.org, net@freebsd.org Subject: Re: 4.4-RC NFS panic Message-ID: <20010820154009.A991@ringworld.oblivion.bg> Mail-Followup-To: "Walter C. Pelissero" , hackers@freebsd.org, net@freebsd.org References: <15232.62492.730149.447791@hyde.lpds.sublink.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15232.62492.730149.447791@hyde.lpds.sublink.org>; from walter@pelissero.org on Mon, Aug 20, 2001 at 12:27:24PM +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 Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote: > [ it seems my original article didn't get through ] > > I recently upgraded to 4.4-RC. > Now my Vaio panics when I use NFS volumes (as client). > The panic is reproducible with a: > > find /some/NFS/mount/point -type f -exec cat {} \; >/dev/null > > Sometime I got a "page fault", sometime a "lockmgr: locking against myself" > > Here is a kgdb session: [snip] > #7 0xc016dbfc in m_freem (m=0xc0738a00) at ../../kern/uipc_mbuf.c:618 > #8 0xc0b59652 in ?? () > #9 0xc0b66b92 in ?? () > #10 0xc0b3fe37 in ?? () > #11 0xc0b606de in ?? () > #12 0xc0b5f11b in ?? () > #13 0xc023b75d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, All those ??'s are the result of kgdb being unable to look inside a kernel module. Are you loading NFS as a module? What other modules are loaded at the time of the panic? Could you try compiling them statically into the kernel, see if the panic still happens, but with more debugging information? G'luck, Peter -- If this sentence didn't exist, somebody would have invented it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 6:10:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id D4E8F37B40D for ; Mon, 20 Aug 2001 06:10:05 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.3+3.4W/8.11.3) with ESMTP/inet id f7KD8Wa38955; Mon, 20 Aug 2001 22:08:33 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: hackers@freebsd.org In-Reply-To: <200108200922.f7K9MUU78293@hak.lan.Awfulhak.org> References: <200108200922.f7K9MUU78293@hak.lan.Awfulhak.org> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) 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: brian@Awfulhak.org Subject: Re: IPv6 DAD avoidance Date: Mon, 20 Aug 2001 22:08:27 +0900 Message-Id: <20010820220827O.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 brian> Would it be worth bringing up the subject of adding an IFF_ flag that brian> can be SIOCSIFFLAGS'd into the interface with the kame team ? I cannot tell it's good and/or standard-compliant things or not... but, brian> If you think it's worth bringing up with the kame guys, can you tell brian> me where I should send the mail (which list address) ? Thanks. How about snap-users@kame.net? This list is for KAME snapshot users, however it is also for technical discussions about KAME specification and implementations. See http://www.kame.net/snap-users/ for more detail. -- - 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 Mon Aug 20 8: 4:40 2001 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 8379037B40F for ; Mon, 20 Aug 2001 08:04:37 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f7KF4GP41786; Mon, 20 Aug 2001 11:04:17 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 20 Aug 2001 11:04:15 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Makoto MATSUSHITA Cc: brian@Awfulhak.org, hackers@freebsd.org Subject: Re: IPv6 DAD avoidance In-Reply-To: <20010820220827O.matusita@jp.FreeBSD.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 On Mon, 20 Aug 2001, Makoto MATSUSHITA wrote: > brian> Would it be worth bringing up the subject of adding an IFF_ flag that > brian> can be SIOCSIFFLAGS'd into the interface with the kame team ? > > I cannot tell it's good and/or standard-compliant things or not... but, > > brian> If you think it's worth bringing up with the kame guys, can you tell > brian> me where I should send the mail (which list address) ? Thanks. > > How about snap-users@kame.net? This list is for KAME snapshot users, > however it is also for technical discussions about KAME specification > and implementations. See http://www.kame.net/snap-users/ for more > detail. For those who use IMAP and are interested, I have an archive of the last couple of years of snap-users on my anonymous IMAP server, cyrus.watson.org. The mailbox name is lists.sec.kame.snap-users. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 8: 6:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pelissero.org (dyn21-37.sftm-212-159.plus.net [212.159.37.21]) by hub.freebsd.org (Postfix) with ESMTP id 59F8637B40A; Mon, 20 Aug 2001 08:06:39 -0700 (PDT) (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.11.5/8.9.3) id f7KF6YZ01196; Mon, 20 Aug 2001 16:06:34 +0100 (BST) (envelope-from wcp) From: "Walter C. Pelissero" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15233.10106.74748.478197@hyde.lpds.sublink.org> Date: Mon, 20 Aug 2001 16:06:34 +0100 To: hackers@freebsd.org, mobile@freebsd.org Subject: 4.4-RC freezes during boot X-Mailer: VM 6.90 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP 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 Upgrading to 4.4-RC a couple of new problems have shown up on my laptop (Vaio PCG-XG9). Beside the already mentioned NFS panic (see freebsd-hackers or freebsd-net), now the bootstrap phase freezes somewhere after: pcic1: Event mask 0x9 The system seems to be frozen beside that if I remove or insert the PCMCIA card on that slot I see appear messages of the same type (sometime the mask is 0x4 or 0x2). If I switch off the machine (Ctrl-Alt-DEL doesn't work) and then on, usually the problem goes away. I couldn't figure out if the problem is really in the PCCARD driver, but you may be interested to know that usually after that message, during a successful bootstrap, I see this one: ata1-slave: ata_command: timeout waiting for intr Another problem after the upgrade to 4.4-RC has been a "broken" sound coming from the speakers. At boot time the driver says: pcm0: port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 0xfedf8000-0xfedfffff irq 9 at device 9.0 on pci0 The playing of MP3 files seems to be all right, but the playing of mono wav files often results in a small gap short after the beginning of the sound. This problem wasn't there in 4.3-STABLE. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 8:48:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A426837B40D; Mon, 20 Aug 2001 08:48:27 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7KFmPq35134; Mon, 20 Aug 2001 09:48:26 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7KFmPW51500; Mon, 20 Aug 2001 09:48:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108201548.f7KFmPW51500@harmony.village.org> To: walter@pelissero.org Subject: Re: 4.4-RC freezes during boot Cc: hackers@FreeBSD.ORG, mobile@FreeBSD.ORG In-reply-to: Your message of "Mon, 20 Aug 2001 16:06:34 BST." <15233.10106.74748.478197@hyde.lpds.sublink.org> References: <15233.10106.74748.478197@hyde.lpds.sublink.org> Date: Mon, 20 Aug 2001 09:48:25 -0600 From: Warner Losh 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 <15233.10106.74748.478197@hyde.lpds.sublink.org> "Walter C. Pelissero" writes: : Upgrading to 4.4-RC a couple of new problems have shown up on my : laptop (Vaio PCG-XG9). Beside the already mentioned NFS panic (see : freebsd-hackers or freebsd-net), now the bootstrap phase freezes : somewhere after: : : pcic1: Event mask 0x9 RC1 has issues with pccard. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 8:49:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by hub.freebsd.org (Postfix) with ESMTP id 0A73137B408; Mon, 20 Aug 2001 08:48:59 -0700 (PDT) (envelope-from darrylo@soco.agilent.com) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id 54852A55; Mon, 20 Aug 2001 09:48:58 -0600 (MDT) Received: from mina.soco.agilent.com (mina.soco.agilent.com [141.121.54.157]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id DE0E487A; Mon, 20 Aug 2001 09:48:57 -0600 (MDT) Received: from mina.soco.agilent.com (darrylo@localhost [127.0.0.1]) by mina.soco.agilent.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id IAA29694; Mon, 20 Aug 2001 08:48:57 -0700 (PDT) Message-Id: <200108201548.IAA29694@mina.soco.agilent.com> To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: secure Filesystem Reply-To: Darryl Okahata In-Reply-To: Your message of "Sat, 18 Aug 2001 14:48:19 PDT." <200108182148.f7ILmJS01950@mass.dis.org> Mime-Version: 1.0 (generated by tm-edit 1.6) Content-Type: text/plain; charset=US-ASCII Date: Mon, 20 Aug 2001 08:48:57 -0700 From: Darryl Okahata 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 Mike Smith wrote: > > The memory is not freed until you unmount (and then, the memory is > > only free'd for use by other cfs mounts -- the process size does not, of > > course, shrink). > > It doesn't? Does it just use malloc for these structs? When you say "of > course", you kinda imply you're thinking of the "bad old" malloc > behaviour... While it uses malloc(), memory seems to be fragmented such that the process doesn't shrink (or doesn't shrink much -- memory leak, perhaps?). I haven't looked into exactly why, and was largely lamenting the insult after injury .... -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 9:30: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by hub.freebsd.org (Postfix) with SMTP id 35E9137B405 for ; Mon, 20 Aug 2001 09:29:50 -0700 (PDT) (envelope-from sandeepj@research.bell-labs.com) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Aug 20 12:29:50 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f7KGTcl59353 for ; Mon, 20 Aug 2001 12:29:38 -0400 (EDT) Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA05309 for ; Mon, 20 Aug 2001 12:29:38 -0400 (EDT) Message-ID: <3B813AF2.BC7C726@research.bell-labs.com> Date: Mon, 20 Aug 2001 12:29:38 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: long-term kernel locks 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 Hi there, I need some mechanism to hold long-term locks (across context switches) while using kernel threads (kthread_*) and lockmgr() looked like the right thing to use. I am running FreeBSD 4.1 on a uniprocessor (..the questions are similar with 4.3) Looking at kern_lock.c, I see that lockmgr() uses simple locks. On a UP system, simple locks are turned off. I dont see any way to prevent a context switch while the kernel thread is in the lockmgr code - after going thru a simple_lock() call. Is this correct ? So my questions are : 1) Is lockmgr safe ? 2) Are there other sync primitives that can be used between two kernel entities (i can move to 4.3) 3) What is the use of simplelock_recurse in kern_lock.c ? TIA, -Sandeep To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 10: 8:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.taconic.net (mail.taconic.net [205.231.144.5]) by hub.freebsd.org (Postfix) with ESMTP id 823EF37B408 for ; Mon, 20 Aug 2001 10:08:41 -0700 (PDT) (envelope-from kish@coyotepoint.com) Received: from coyotepoint.com (taconic-aa-p486.taconic.net [205.231.145.232]) by mail.taconic.net (8.10.2+Sun/8.11.0) with ESMTP id f7KH0Di16208 for ; Mon, 20 Aug 2001 13:00:13 -0400 (EDT) Message-ID: <3B814358.CC708C42@coyotepoint.com> Date: Mon, 20 Aug 2001 13:05:28 -0400 From: Bill Kish X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Open Source Load Balancer 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 Hi All, Sorry if this posting is somewhat off topic, but I think the answer to my question will be found among the subscribers to this list. I'm trying to convince the powers that be here at Coyote Point Systems that we should release the source for our Equalizer load balancer software to the Open Source community. I think I can pull this off, but I'd like to see what sort of interest there might be in this project and perhaps begin recruiting a project team. Any thoughts on the best forum to begin this process? This mostly kernel IP stack code which currently runs on FreeBSD. Thanks in advance, -=BK -- --------------------------------------------------------------- Bill Kish Ph: 650.969.6000 Chief Engineer, 3350 Scott Blvd, Bldg 20 Coyote Point Systems Inc. Santa Clara California 95054 Email: kish@coyotepoint.com http://www.coyotepoint.com/ --------------------------------------------------------------- For support call: 1-888-891-8150 Email: --------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 10:35:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pelissero.org (dyn209-37.sftm-212-159.plus.net [212.159.37.209]) by hub.freebsd.org (Postfix) with ESMTP id E2A0937B40D; Mon, 20 Aug 2001 10:35:02 -0700 (PDT) (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.11.5/8.9.3) id f7KHYwe02231; Mon, 20 Aug 2001 18:34:58 +0100 (BST) (envelope-from wcp) From: "Walter C. Pelissero" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15233.19009.779227.903080@hyde.lpds.sublink.org> Date: Mon, 20 Aug 2001 18:34:57 +0100 To: hackers@freebsd.org, net@freebsd.org Subject: Re: 4.4-RC NFS panic In-Reply-To: <20010820154009.A991@ringworld.oblivion.bg> References: <15232.62492.730149.447791@hyde.lpds.sublink.org> <20010820154009.A991@ringworld.oblivion.bg> X-Mailer: VM 6.90 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP 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 [ third time I retry to post this message on the mailing list ] Peter Pentchev writes: > On Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote: > All those ??'s are the result of kgdb being unable to look inside > a kernel module. Are you loading NFS as a module? Yep. I recompiled a kernel with almost all modules linked in. I forgot some of them but I guess those don't hurt. Now kldstat says: Id Refs Address Size Name 1 4 0xc0100000 298698 kernel 2 1 0xc0399000 30e0 splash_bmp.ko 3 1 0xc039d000 5458 vesa.ko 4 1 0xc0b63000 19000 usb.ko The panic is still easily reproducible and therefore I've got some more details to show you: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". Reading symbols from kernel.debug...done. IdlePTD 4009984 initial pcb at 311680 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x65746e69 fault code = supervisor read, page not present instruction pointer = 0x8:0xc028782e stack pointer = 0x10:0xc780bccc frame pointer = 0x10:0xc780bd08 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 179 (nfsiod) interrupt mask = none trap number = 12 panic: page fault syncing disks... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 done Uptime: 3m35s dumping to dev #ad/0x30001, offset 272736 dump ata0: resetting devices .. done 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at ../../kern/kern_shutdown.c:472 472 if (dumping++) { (kgdb) bt #0 dumpsys () at ../../kern/kern_shutdown.c:472 #1 0xc0159b17 in boot (howto=256) at ../../kern/kern_shutdown.c:312 #2 0xc0159ee4 in poweroff_wait (junk=0xc02cd40c, howto=-1070805201) at ../../kern/kern_shutdown.c:580 #3 0xc0289002 in trap_fatal (frame=0xc780bc8c, eva=1702129257) at ../../i386/i386/trap.c:956 #4 0xc0288cd5 in trap_pfault (frame=0xc780bc8c, usermode=0, eva=1702129257) at ../../i386/i386/trap.c:849 #5 0xc02888bf in trap (frame={tf_fs = 16, tf_es = -1019805680, tf_ds = -1062076400, tf_edi = -1003117116, tf_esi = 1702129257, tf_ebp = -947864312, tf_isp = -947864392, tf_ebx = 6716, tf_edx = -947864124, tf_ecx = 1679, tf_eax = 1589720923, tf_trapno = 12, tf_err = 0, tf_eip = -1071089618, tf_cs = 8, tf_eflags = 66066, tf_esp = 1397686380, tf_ss = 6716}) at ../../i386/i386/trap.c:448 #6 0xc028782e in generic_bcopy () #7 0xc01f994a in nfs_readrpc (vp=0xc78dc300, uiop=0xc780bdc4, cred=0xc0bc9d80) at ../../nfs/nfs_vnops.c:1118 #8 0xc01d3393 in nfs_doio (bp=0xc3373e60, cr=0xc0bc9d80, p=0x0) at ../../nfs/nfs_bio.c:1410 #9 0xc01f348e in nfssvc_iod (p=0xc77baf20) at ../../nfs/nfs_syscalls.c:970 #10 0xc01f1ed3 in nfssvc (p=0xc77baf20, uap=0xc780bf80) at ../../nfs/nfs_syscalls.c:166 #11 0xc02892ad in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077936680, tf_esi = 0, tf_ebp = -1077936776, tf_isp = -947863596, tf_ebx = 2, tf_edx = 1, tf_ecx = 19, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 134515664, tf_cs = 31, tf_eflags = 643, tf_esp = -1077936852, tf_ss = 47}) at ../../i386/i386/trap.c:1155 #12 0xc027d635 in Xint0x80_syscall () #13 0x8048135 in ?? () Side note. I experienced another panic not directly related to NFS. During a high resolution print of a big image (something around 30MB postscript file) on a remote host (the NFS server) I got a panic, which might suggest the problem (if related) is in a deeper level than NFS. The remote printing panic is not so easy to reproduce so I gave up on that front. A nicer remark. The NFS server is up and running with a 4.4-RC (the same as my Vaio) since Friday without a single problem. I'm currently using a 4.3-STABLE and I don't get a panic whatsoever, so I assume the hardware is still all right. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 10:47:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id AD65037B410 for ; Mon, 20 Aug 2001 10:47:09 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7KHl7l52745; Mon, 20 Aug 2001 10:47:07 -0700 (PDT) (envelope-from dillon) Date: Mon, 20 Aug 2001 10:47:07 -0700 (PDT) From: Matt Dillon Message-Id: <200108201747.f7KHl7l52745@earth.backplane.com> To: Sandeep Joshi Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: long-term kernel locks References: <3B813AF2.BC7C726@research.bell-labs.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 :Hi there, : :I need some mechanism to hold long-term locks (across :context switches) while using kernel threads (kthread_*) :and lockmgr() looked like the right thing to use. : :I am running FreeBSD 4.1 on a uniprocessor (..the questions :are similar with 4.3) : :Looking at kern_lock.c, I see that lockmgr() uses simple :locks. On a UP system, simple locks are turned off. :I dont see any way to prevent a context switch while the :kernel thread is in the lockmgr code - after going :thru a simple_lock() call. Is this correct ? : :So my questions are : :1) Is lockmgr safe ? :2) Are there other sync primitives that can be used : between two kernel entities (i can move to 4.3) :3) What is the use of simplelock_recurse in : kern_lock.c ? : :TIA, :-Sandeep Ah, the wonderful world of lockmgr(). This function actually implements long term locks. It uses simplelock() internally to force consistent state for short periods of time - which really only applies to SMP environments, which is why simplelock() is a NOP on UP systems. For an example of long-term in-kernel locks, take a look at kern/vfs_subr.c. Search for 'lockinit' and 'lockmgr' calls. lockmgr() is in fact what you want to use. You should be able to safely ignore the interlock stuff for your purposes. interlock is passed in order to allow lockmgr() to release the simplelock that the caller was holding in order for lockmgr() to be able to sleep, and then gain it back later. i.e. the caller may simplelock() something it is managing and then want to call lockmgr() to get a real lock 'atomically'. The atomicy is achieved by the caller maintaining its hold on the simplelock() through the call to lockmgr(). But simplelock()'s cannot survive context switches so the caller must pass the simplelock to lockmgr() so lockmgr() can release it temporarily when it decides it needs to block. Weird, but it works. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 11: 2:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id 6272237B410 for ; Mon, 20 Aug 2001 11:02:40 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f7KI4RG12335; Mon, 20 Aug 2001 14:04:27 -0400 (EDT) (envelope-from bmilekic) Date: Mon, 20 Aug 2001 14:04:27 -0400 From: Bosko Milekic To: Bill Kish Cc: hackers@FreeBSD.ORG Subject: Re: Open Source Load Balancer Message-ID: <20010820140427.A12257@technokratis.com> References: <3B814358.CC708C42@coyotepoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B814358.CC708C42@coyotepoint.com>; from kish@coyotepoint.com on Mon, Aug 20, 2001 at 01:05:28PM -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 Mon, Aug 20, 2001 at 01:05:28PM -0400, Bill Kish wrote: > > Hi All, > > Sorry if this posting is somewhat off topic, but I think the answer to my > question will be found among the subscribers to this list. > > I'm trying to convince the powers that be here at Coyote Point Systems that > we should release the source for our Equalizer load balancer software to the > Open Source community. I think I can pull this off, but I'd like to see what > sort of interest there might be in this project and perhaps begin recruiting > a project team. > > Any thoughts on the best forum to begin this process? This mostly kernel IP > stack code which currently runs on FreeBSD. Most probably freebsd-net@freebsd.org - assuming of course that this is some sort of `network load balancer.' > Thanks in advance, > > -=BK > -- > --------------------------------------------------------------- > Bill Kish Ph: 650.969.6000 > Chief Engineer, 3350 Scott Blvd, Bldg 20 > Coyote Point Systems Inc. Santa Clara California 95054 > Email: kish@coyotepoint.com http://www.coyotepoint.com/ > --------------------------------------------------------------- > For support call: 1-888-891-8150 Email: > --------------------------------------------------------------- -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 11:23:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 3A0A037B415; Mon, 20 Aug 2001 11:23:23 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA26908; Mon, 20 Aug 2001 11:23:14 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15233.19009.779227.903080@hyde.lpds.sublink.org> Date: Mon, 20 Aug 2001 11:23:21 -0700 (PDT) From: John Baldwin To: "Walter C. Pelissero" Subject: Re: 4.4-RC NFS panic Cc: net@FreeBSD.org, hackers@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 20-Aug-01 Walter C. Pelissero wrote: > [ third time I retry to post this message on the mailing list ] > > Peter Pentchev writes: > > On Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote: > > All those ??'s are the result of kgdb being unable to look inside > > a kernel module. Are you loading NFS as a module? > > Yep. I recompiled a kernel with almost all modules linked in. I > forgot some of them but I guess those don't hurt. > Now kldstat says: > > Id Refs Address Size Name > 1 4 0xc0100000 298698 kernel > 2 1 0xc0399000 30e0 splash_bmp.ko > 3 1 0xc039d000 5458 vesa.ko > 4 1 0xc0b63000 19000 usb.ko > > The panic is still easily reproducible and therefore I've got some > more details to show you: > > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-freebsd". > Reading symbols from kernel.debug...done. > IdlePTD 4009984 > initial pcb at 311680 > panicstr: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x65746e69 "etni" Looks like a string has gotten spammed across a data structure or a weird pointer, etc. From the previous panic: > fault virtual address = 0x33693d55 "3i=U" That one looks more suspicious, but could still be part of a string of some sort. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://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 Mon Aug 20 11:46:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id DDE7A37B409; Mon, 20 Aug 2001 11:46:38 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA38102; Mon, 20 Aug 2001 11:52:40 -0700 (PDT) Date: Mon, 20 Aug 2001 11:52:39 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: "Walter C. Pelissero" , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic 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 remember it's littel endian On Mon, 20 Aug 2001, John Baldwin wrote: > > fault virtual address = 0x65746e69 > "etni" "inet" > > Looks like a string has gotten spammed across a data structure or a weird > pointer, etc. > > From the previous panic: > > > fault virtual address = 0x33693d55 > "3i=U" > "U=i3" (as in U=i386_xxx;" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 11:46:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 9941E37B40E; Mon, 20 Aug 2001 11:46:42 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA38108; Mon, 20 Aug 2001 11:53:42 -0700 (PDT) Date: Mon, 20 Aug 2001 11:53:42 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: "Walter C. Pelissero" , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic 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 > "etni" oops I mean "inte" (as in "integer" > > Looks like a string has gotten spammed across a data structure or a weird > pointer, etc. > > From the previous panic: > > > fault virtual address = 0x33693d55 > "3i=U" > > That one looks more suspicious, but could still be part of a string of some > sort. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.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 Mon Aug 20 11:51:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pelissero.org (dyn192-37.sftm-212-159.plus.net [212.159.37.192]) by hub.freebsd.org (Postfix) with ESMTP id C28F437B41D; Mon, 20 Aug 2001 11:51:25 -0700 (PDT) (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.11.5/8.9.3) id f7KIpIs15182; Mon, 20 Aug 2001 19:51:18 +0100 (BST) (envelope-from wcp) From: "Walter C. Pelissero" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15233.23589.587884.764408@hyde.lpds.sublink.org> Date: Mon, 20 Aug 2001 19:51:17 +0100 To: John Baldwin Cc: net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic In-Reply-To: References: <15233.19009.779227.903080@hyde.lpds.sublink.org> X-Mailer: VM 6.90 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP 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 Baldwin writes: > > fault virtual address = 0x65746e69 > "etni" > > Looks like a string has gotten spammed across a data structure or a > weird pointer, etc. Whatever mess happend, I've got some news for you that should remove the NFS module from the list of possible causes. Currently I'm running an old 4.3-STABLE kernel and kldstat shows: Id Refs Address Size Name 1 6 0xc0000000 40000000 kernel 2 1 0xc0ae0000 d000 msdos.ko 3 1 0xc0b0f000 6000 procfs.ko 4 1 0xc0b18000 4000 kernfs.ko 5 1 0xc0b3b000 4d000 nfs.ko <--- ! 6 1 0xc0bae000 12000 linux.ko That is, since my /modules is new, I've loaded the brand new 4.4-RC's NFS module, and it works without a glitch (at least for now). This enforces my belief that there is something broken in some deeper layer of the network code (see the remote printing issue). The time stamp of the older kernel is -r-xr-xr-x 1 root wheel 2408052 Jul 29 15:19 /kernel.good It's a pretty long period (almost a month) but maybe is possible to track down the mods to the network code till now. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 11:58:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 615C637B418; Mon, 20 Aug 2001 11:58:20 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 Aug 2001 19:58:19 +0100 (BST) Date: Mon, 20 Aug 2001 19:58:18 +0100 From: David Malone To: "Walter C. Pelissero" Cc: John Baldwin , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic Message-ID: <20010820195818.A68554@walton.maths.tcd.ie> References: <15233.19009.779227.903080@hyde.lpds.sublink.org> <15233.23589.587884.764408@hyde.lpds.sublink.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15233.23589.587884.764408@hyde.lpds.sublink.org>; from walter@pelissero.org on Mon, Aug 20, 2001 at 07:51:17PM +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 Mon, Aug 20, 2001 at 07:51:17PM +0100, Walter C. Pelissero wrote: > This enforces my belief that there is something broken in some deeper > layer of the network code (see the remote printing issue). Just out of curiosity, what sort of network card is your Vaio using? Someone else is seeing network related panics that might be related to freeing an mbuf that's in use, and it's possible this might be related. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 12:47:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by hub.freebsd.org (Postfix) with SMTP id 5944937B419 for ; Mon, 20 Aug 2001 12:47:50 -0700 (PDT) (envelope-from sandeepj@research.bell-labs.com) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Aug 20 15:47:44 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Mon Aug 20 15:48:03 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA28845; Mon, 20 Aug 2001 15:47:32 -0400 (EDT) Message-ID: <3B816954.9CF1134E@research.bell-labs.com> Date: Mon, 20 Aug 2001 15:47:32 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: freebsd-hackers@freebsd.org Subject: Re: long-term kernel locks References: <3B813AF2.BC7C726@research.bell-labs.com> <200108201747.f7KHl7l52745@earth.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 Matt Ok I see..the interlock is a lock on a collection (e.g on vfs mount list) and it can be released once the simple lock within the to-be-locked object has been acquired. These are really spin locks, now that I saw simplelock.s One more clarification if you will.. :-) What is the purpose of the "splhigh" in acquire() ? Is it this that prevents an involuntary context switch in a UP system , while the lock variables are being modified by acquire() ? -Sandeep Matt Dillon wrote: > > :Hi there, > : > :I need some mechanism to hold long-term locks (across > :context switches) while using kernel threads (kthread_*) > :and lockmgr() looked like the right thing to use. > : > :I am running FreeBSD 4.1 on a uniprocessor (..the questions > :are similar with 4.3) > : > :Looking at kern_lock.c, I see that lockmgr() uses simple > :locks. On a UP system, simple locks are turned off. > :I dont see any way to prevent a context switch while the > :kernel thread is in the lockmgr code - after going > :thru a simple_lock() call. Is this correct ? > : > :So my questions are : > :1) Is lockmgr safe ? > :2) Are there other sync primitives that can be used > : between two kernel entities (i can move to 4.3) > :3) What is the use of simplelock_recurse in > : kern_lock.c ? > : > :TIA, > :-Sandeep > > Ah, the wonderful world of lockmgr(). This function actually > implements long term locks. It uses simplelock() internally > to force consistent state for short periods of time - which really > only applies to SMP environments, which is why simplelock() is a > NOP on UP systems. > > For an example of long-term in-kernel locks, take a look at > kern/vfs_subr.c. Search for 'lockinit' and 'lockmgr' calls. > lockmgr() is in fact what you want to use. > > You should be able to safely ignore the interlock stuff for your > purposes. interlock is passed in order to allow lockmgr() to > release the simplelock that the caller was holding in order for > lockmgr() to be able to sleep, and then gain it back later. > > i.e. the caller may simplelock() something it is managing and then > want to call lockmgr() to get a real lock 'atomically'. The atomicy > is achieved by the caller maintaining its hold on the simplelock() > through the call to lockmgr(). But simplelock()'s cannot survive > context switches so the caller must pass the simplelock to lockmgr() > so lockmgr() can release it temporarily when it decides it needs to > block. Weird, but it works. > > -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 12:56:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1E37D37B403 for ; Mon, 20 Aug 2001 12:56:23 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7KJuKt55214; Mon, 20 Aug 2001 12:56:20 -0700 (PDT) (envelope-from dillon) Date: Mon, 20 Aug 2001 12:56:20 -0700 (PDT) From: Matt Dillon Message-Id: <200108201956.f7KJuKt55214@earth.backplane.com> To: Sandeep Joshi Cc: freebsd-hackers@freebsd.org Subject: Re: long-term kernel locks References: <3B813AF2.BC7C726@research.bell-labs.com> <200108201747.f7KHl7l52745@earth.backplane.com> <3B816954.9CF1134E@research.bell-labs.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 :Matt : :Ok I see..the interlock is a lock on a collection (e.g :on vfs mount list) and it can be released once the simple :lock within the to-be-locked object has been acquired. :These are really spin locks, now that I saw simplelock.s : :One more clarification if you will.. :-) : :What is the purpose of the "splhigh" in acquire() ? : :Is it this that prevents an involuntary context switch in :a UP system , while the lock variables are being modified :by acquire() ? : :-Sandeep In -stable there are no involuntary context switches in kernel mode and only one cpu can truely be running kernel code at any given moment, but interrupts can still preempt (temporarily) the mainline code. So all you need to protect against are interrupts. splhigh() effectively disables interrupts - because an interrupt might call code that conflicts with the mainline code in question. There are places in the mainline code that interrupts never touch where the mainline code thus does not bother to use splhigh() or any spl*() stuff at all. There are other places in the mainline code that are also called from interrupts and that is where the spl*() protection is required. In -current the situation is vastly different. Involuntary context switches can occur at almost any time and more then one cpu may be running kernel code at any given instance, so structures must be protected by mutexes at all times. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 13:22:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tara.freenix.org (keltia.freenix.org [62.4.20.87]) by hub.freebsd.org (Postfix) with ESMTP id 1597637B41A; Mon, 20 Aug 2001 13:22:40 -0700 (PDT) (envelope-from roberto@tara.freenix.org) Received: by tara.freenix.org (Postfix/TLS, from userid 101) id DE6AF208; Mon, 20 Aug 2001 22:22:38 +0200 (CEST) Date: Mon, 20 Aug 2001 22:22:38 +0200 From: Ollivier Robert To: net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic Message-ID: <20010820222238.A84351@tara.freenix.org> Mail-Followup-To: net@FreeBSD.org, hackers@FreeBSD.org References: <15233.19009.779227.903080@hyde.lpds.sublink.org> <15233.23589.587884.764408@hyde.lpds.sublink.org> <20010820195818.A68554@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010820195818.A68554@walton.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Mon, Aug 20, 2001 at 07:58:18PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT K6-3D/266 & 2x PPro/200 SMP 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 According to David Malone: > Just out of curiosity, what sort of network card is your Vaio using? > Someone else is seeing network related panics that might be related If this is a VAIO with built-in ethernet, then it is an fxp card. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 15:41:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id D112237B409 for ; Mon, 20 Aug 2001 15:41:49 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AFAD981D15; Mon, 20 Aug 2001 17:41:39 -0500 (CDT) Date: Mon, 20 Aug 2001 17:41:39 -0500 From: Alfred Perlstein To: Bill Kish Cc: hackers@freebsd.org Subject: Re: Open Source Load Balancer Message-ID: <20010820174139.C81307@elvis.mu.org> References: <3B814358.CC708C42@coyotepoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B814358.CC708C42@coyotepoint.com>; from kish@coyotepoint.com on Mon, Aug 20, 2001 at 01:05:28PM -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 * Bill Kish [010820 12:09] wrote: > > Hi All, > > Sorry if this posting is somewhat off topic, but I think the answer to my > question will be found among the subscribers to this list. > > I'm trying to convince the powers that be here at Coyote Point Systems that > we should release the source for our Equalizer load balancer software to the > Open Source community. I think I can pull this off, but I'd like to see what > sort of interest there might be in this project and perhaps begin recruiting > a project team. > > Any thoughts on the best forum to begin this process? This mostly kernel IP > stack code which currently runs on FreeBSD. If the code can be put into FreeBSD with minimal impact on the tcp stack when it's not active I'd help you guys integrate it. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 15:46:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.newgold.net (aphex.newgold.net [209.42.222.44]) by hub.freebsd.org (Postfix) with SMTP id BC21F37B408 for ; Mon, 20 Aug 2001 15:46:27 -0700 (PDT) (envelope-from jmallett@mail.newgold.net) Received: (qmail 14064 invoked by uid 1000); 20 Aug 2001 22:46:25 -0000 Date: Mon, 20 Aug 2001 22:46:25 +0000 From: Joseph Mallett To: Julian Elischer Cc: John Baldwin , "Walter C. Pelissero" , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic Message-ID: <20010820224625.A14002@NewGold.NET> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i Organisation: New Gold Technology 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 > > "etni" > > "inet" > Your string reversal function is buggy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 16:25:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 7518337B405; Mon, 20 Aug 2001 16:25:07 -0700 (PDT) Subject: Where to put new bus_dmamap_load_mbuf() code To: hackers@freebsd.org Date: Mon, 20 Aug 2001 16:25:07 -0700 (PDT) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010820232507.7518337B405@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) 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 Okay, I decided today to write a bus_dmamap_load_mbuf() routine to make it a little easier to convert the PCI NIC drivers to use the busdma API. It's not the same as the NetBSD code. There are four new functions: bus_dmamap_load_mbuf() bus_dmamap_unload_mbuf() bus_dmamap_sync_mbuf() bus_dmamap_destroy_mbuf() This is more or less in keeping with the existing API, except the new routines work exclusively on mbuf lists. The thing I need to figure out now is where to put the code. The current suggestion from jhb is to create the following two new files: sys/kern/kern_busdma.c sys/sys/busdma.h The functions are machine-independent, so they shouldn't be in sys///busdma_machdep.c. I mean, they could go there, but that would just result in code duplication. If somebody has a better suggestion, now's the time to speak up. Please let's avoid creating another bikeshed over this. Current code snapshot resides at: http://www.freebsd.org/~wpaul/busdma There's also a modified version if the Adaptec "starfire" driver there which uses the new routines. I'm running this version of the driver on a test box in the lab right now. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 16:34:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id AD05437B403; Mon, 20 Aug 2001 16:34:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7KNYDI69794; Mon, 20 Aug 2001 16:34:14 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 20 Aug 2001 16:34:13 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Bill Paul Cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: <20010820232507.7518337B405@hub.freebsd.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 Yay! The current suggestion is fine except that each platform might have a more efficient, or even required, actual h/w mechanism for mapping mbufs. I'd also be a little concerned with the way you're overloading stuff into mbuf itself- but I'm a little shakier on this. Finally- why not make this an inline? -matt On Mon, 20 Aug 2001, Bill Paul wrote: > Okay, I decided today to write a bus_dmamap_load_mbuf() routine to > make it a little easier to convert the PCI NIC drivers to use the > busdma API. It's not the same as the NetBSD code. There are four > new functions: > > bus_dmamap_load_mbuf() > bus_dmamap_unload_mbuf() > bus_dmamap_sync_mbuf() > bus_dmamap_destroy_mbuf() > > This is more or less in keeping with the existing API, except the new > routines work exclusively on mbuf lists. The thing I need to figure > out now is where to put the code. The current suggestion from jhb is > to create the following two new files: > > sys/kern/kern_busdma.c > sys/sys/busdma.h > > The functions are machine-independent, so they shouldn't be in > sys///busdma_machdep.c. I mean, they could go there, but > that would just result in code duplication. If somebody has a better > suggestion, now's the time to speak up. Please let's avoid creating > another bikeshed over this. > > Current code snapshot resides at: > > http://www.freebsd.org/~wpaul/busdma > > There's also a modified version if the Adaptec "starfire" driver there > which uses the new routines. I'm running this version of the driver on > a test box in the lab right now. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos > ============================================================================= > > 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 Aug 20 16:37:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 7E1E637B401; Mon, 20 Aug 2001 16:37:12 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7KNbBI69852; Mon, 20 Aug 2001 16:37:12 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 20 Aug 2001 16:37:11 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Bill Paul Cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code 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 Another thing- maybe I'm confused- but I still don't see why you want to require the creating of a map each time you want to load an mbuf chain. Wouldn't it be better and more efficient to let the driver decide when and where the map is created and just use the common code for loads/unloads? On Mon, 20 Aug 2001, Matthew Jacob wrote: > > Yay! > > The current suggestion is fine except that each platform might have a more > efficient, or even required, actual h/w mechanism for mapping mbufs. > > I'd also be a little concerned with the way you're overloading stuff into mbuf > itself- but I'm a little shakier on this. > > Finally- why not make this an inline? > > -matt > > > On Mon, 20 Aug 2001, Bill Paul wrote: > > > Okay, I decided today to write a bus_dmamap_load_mbuf() routine to > > make it a little easier to convert the PCI NIC drivers to use the > > busdma API. It's not the same as the NetBSD code. There are four > > new functions: > > > > bus_dmamap_load_mbuf() > > bus_dmamap_unload_mbuf() > > bus_dmamap_sync_mbuf() > > bus_dmamap_destroy_mbuf() > > > > This is more or less in keeping with the existing API, except the new > > routines work exclusively on mbuf lists. The thing I need to figure > > out now is where to put the code. The current suggestion from jhb is > > to create the following two new files: > > > > sys/kern/kern_busdma.c > > sys/sys/busdma.h > > > > The functions are machine-independent, so they shouldn't be in > > sys///busdma_machdep.c. I mean, they could go there, but > > that would just result in code duplication. If somebody has a better > > suggestion, now's the time to speak up. Please let's avoid creating > > another bikeshed over this. > > > > Current code snapshot resides at: > > > > http://www.freebsd.org/~wpaul/busdma > > > > There's also a modified version if the Adaptec "starfire" driver there > > which uses the new routines. I'm running this version of the driver on > > a test box in the lab right now. > > > > -Bill > > > > -- > > ============================================================================= > > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > > wpaul@windriver.com | Wind River Systems > > ============================================================================= > > "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos > > ============================================================================= > > > > 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 Aug 20 16:38:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pelissero.org (dyn90-32.sftm-212-159.plus.net [212.159.32.90]) by hub.freebsd.org (Postfix) with ESMTP id B469337B403; Mon, 20 Aug 2001 16:38:46 -0700 (PDT) (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.11.5/8.9.3) id f7KNcWO00667; Tue, 21 Aug 2001 00:38:32 +0100 (BST) (envelope-from wcp) From: "Walter C. Pelissero" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15233.40823.749512.643101@hyde.lpds.sublink.org> Date: Tue, 21 Aug 2001 00:38:31 +0100 To: David Malone Cc: John Baldwin , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic In-Reply-To: <20010820195818.A68554@walton.maths.tcd.ie> References: <15233.19009.779227.903080@hyde.lpds.sublink.org> <15233.23589.587884.764408@hyde.lpds.sublink.org> <20010820195818.A68554@walton.maths.tcd.ie> X-Mailer: VM 6.90 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP 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 David Malone writes: > On Mon, Aug 20, 2001 at 07:51:17PM +0100, Walter C. Pelissero wrote: > > This enforces my belief that there is something broken in some deeper > > layer of the network code (see the remote printing issue). > > Just out of curiosity, what sort of network card is your Vaio using? > Someone else is seeing network related panics that might be related > to freeing an mbuf that's in use, and it's possible this might be > related. Mmmm, you might be right. I'm using a 3com 589, therefore I'm using the ep driver. Unfortunately I don't have a different PCMCIA network card at hand, but I can try to reverse the crash test with my server. Yes, the server is running exactly the same version (4.4-RC) but uses the de driver. So I did and, guess what, the find/cat test on my server over an NFS mounted directory from my Vaio ran without a problem. I've just done a further test. I've mounted a directory tree from Vaio to Vaio using localhost (lo driver) and the test has run smoothly. So chances would be good the bug is in the ep driver. Unfortunately... $ ls -l /sys/dev/ep total 70 -rw-r--r-- 1 root wheel 23554 Jul 17 2000 if_ep.c -rw-r--r-- 1 root wheel 6202 Jan 14 2000 if_ep_eisa.c -rw-r--r-- 1 root wheel 10046 Dec 16 2000 if_ep_isa.c -rw-r--r-- 1 root wheel 4584 Oct 27 1999 if_ep_mca.c -rw-r--r-- 1 root wheel 6950 Aug 9 2000 if_ep_pccard.c -rw-r--r-- 1 root wheel 13935 Jan 12 2000 if_epreg.h -rw-r--r-- 1 root wheel 2667 May 24 2000 if_epvar.h none of the modules belonging to the ep driver has been touched for a long time. Side note. Regarding a different problem I've mentioned in freebsd-hackers I've been told 4.4-RC has got problems with the PCCARD code. Whether that can influence the ep driver is beyond my knowledge. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 17: 6:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 92CF937B406; Mon, 20 Aug 2001 17:06:30 -0700 (PDT) Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: from Matthew Jacob at "Aug 20, 2001 04:37:11 pm" To: mjacob@feral.com Date: Mon, 20 Aug 2001 17:06:30 -0700 (PDT) Cc: hackers@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010821000630.92CF937B406@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) 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 > > Another thing- maybe I'm confused- but I still don't see why you want to > require the creating of a map each time you want to load an mbuf > chain. Wouldn't it be better and more efficient to let the driver decide when > and where the map is created and just use the common code for loads/unloads? Every hear the phrase "you get what you pay for?" The API isn't all that clear, and we don't have a man page or document that describes in detail how to use it properly. Rather than whining about that, I decided to tinker with it and Use The Source, Luke (tm). This is the result. My understanding is that you need a dmamap for every buffer that you want to map into bus space. Each mbuf has a single data buffer associated with it (either the data area in the mbuf itself, or external storage). We're not allowed to make assumptions about where these buffers are. Also, a single ethernet frame can be fragmented across multiple mbufs in a list. So unless I'm mistaken, for each mbuf in an mbuf list, what we have to do is this: - create a bus_dmamap_t for the data area in the mbuf using bus_dmamap_create() - do the physical to bus mapping with bus_dmamap_load() - call bus_dmamap_sync() as needed (might handle copying if bounce buffers are required) - - do post-DMA sync as needed (again, might require bounce copying) - call bus_dmamap_unload() to un-do the bus mapping (which might free bounce buffers if some were allocated by bus_dmamap_load()) - destroy the bus_dmamap_t One memory region, one DMA map. It seems to me that you can't use a single dmamap for multiple memory buffers, unless you make certain assumptions about where in physical memory those buffers reside, and I thought the idea of busdma was to provide a consistent, opaque API so that you would not have to make any assumptions. Now if I've gotten any of this wrong, please tell me how I should be doing it. Remember to show all work. I don't give partial credit, nor do I grade on a curve. > > Yay! > > > > The current suggestion is fine except that each platform might have a more > > efficient, or even required, actual h/w mechanism for mapping mbufs. It might, but right now, it doesn't. All I have to work with is the existing API. I'm not here to stick my fingers in it and change it all around. I just want to add a bit of code on top of it so that I don't have to go through quite so many contortions when I use the API in network adapter drivers. > > I'd also be a little concerned with the way you're overloading stuff into mbuf > > itself- but I'm a little shakier on this. I thought about this. Like it says in the comments, at the device driver level, you're almost never going to be using some of the pointers in the mbuf header. On the RX side, *we* (i.e. the driver) are allocating the mbufs, so we can do whatever the heck we want with them until such time as we hand them off to ether_input(), and by then we will have put things back the way they were. For the TX side, by the time we get the mbufs off the send queue, we always know we're going to have just an mbuf list (and not an mbuf chain), and we're going to toss the mbufs once we're done with them, so we can trample on certain things that we know don't matter to the OS or network stack anymore. The alternatives are: - Allocate some extra space in the DMA descriptor structures for the necessary bus_dmamap_t pointers. This is tricky with this particular NIC, and a little awkward. - Allocate my own private arrays of bus_dmamap_t that mirror the DMA rings. This is yet more memory I need to allocate and free at device attach and detach time. I've got space in the mbuf header. It's not being used. It's right where I need it. Why not take advantage of it? > > Finally- why not make this an inline? Er... because that idea offended my delicate sensibilities? :) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 17:57:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B367E37B407; Mon, 20 Aug 2001 17:57:43 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7L0vhG39115; Mon, 20 Aug 2001 17:57:43 -0700 (PDT) (envelope-from obrien) Date: Mon, 20 Aug 2001 17:57:43 -0700 From: "David O'Brien" To: hackers@freebsd.org Subject: header polution Message-ID: <20010820175743.A33795@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 When compiling the `dict' port, one gets: In file included from /usr/include/machine/signal.h:54, from /usr/include/sys/signal.h:178, from /usr/include/signal.h:44, from dict.h:33, from clientparse.y:25: /usr/include/machine/trap.h:105: warning: `T_USER' redefined This seems very wrong. Can't we rename "T_USER" in the kernel to "_T_USER", or wrap it in _KERNEL? The comment in machine/signal.h(x86) says: #include /* codes for SIGILL, SIGFPE */ but does that mean we must expose the entire contents of trap.h to userland? The problem is T_ is very common in lex source. -- -- David (obrien@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 Aug 20 20: 9:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0CD4637B405; Mon, 20 Aug 2001 20:09:53 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7L39oq37037; Mon, 20 Aug 2001 21:09:51 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7L39oW55481; Mon, 20 Aug 2001 21:09:50 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108210309.f7L39oW55481@harmony.village.org> To: walter@pelissero.org Subject: Re: 4.4-RC NFS panic Cc: David Malone , John Baldwin , net@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 21 Aug 2001 00:38:31 BST." <15233.40823.749512.643101@hyde.lpds.sublink.org> References: <15233.40823.749512.643101@hyde.lpds.sublink.org> <15233.19009.779227.903080@hyde.lpds.sublink.org> <15233.23589.587884.764408@hyde.lpds.sublink.org> <20010820195818.A68554@walton.maths.tcd.ie> Date: Mon, 20 Aug 2001 21:09:50 -0600 From: Warner Losh 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 <15233.40823.749512.643101@hyde.lpds.sublink.org> "Walter C. Pelissero" writes: : Mmmm, you might be right. I'm using a 3com 589, therefore I'm using : the ep driver. The ep driver has been a little flakey under heavy load (like NFS) for a while. : Side note. Regarding a different problem I've mentioned in : freebsd-hackers I've been told 4.4-RC has got problems with the PCCARD : code. Whether that can influence the ep driver is beyond my : knowledge. No. It is a works or doesn't kinda bug. If you are getting to the point of mounting with NFS, the network works. Unless you are seeing 1s ping times. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 22:51:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 7432437B408; Mon, 20 Aug 2001 22:50:54 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7L5orI71797; Mon, 20 Aug 2001 22:50:54 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 20 Aug 2001 22:50:38 -0700 (PDT) From: Matthew Jacob Reply-To: To: Bill Paul Cc: , Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: <20010821000630.92CF937B406@hub.freebsd.org> Message-ID: <20010820223007.I39850-100000@wonky.feral.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, 20 Aug 2001, Bill Paul wrote: > Every hear the phrase "you get what you pay for?" The API isn't all that > clear, and we don't have a man page or document that describes in detail > how to use it properly. Rather than whining about that, I decided to > tinker with it and Use The Source, Luke (tm). This is the result. Well, I'm more familiar with the NetBSD BusDma code, which is similar, and heavily documented. I'm also one of the principle authors of the Solaris DKI/DDI, which is *also* heavily documented, so I have some small notion of how a few of these subsystems are supposed to work, and where documentation exists for these- and similar systems (e.g., UDI). > > My understanding is that you need a dmamap for every buffer that you want > to map into bus space. Each mbuf has a single data buffer associated with > it (either the data area in the mbuf itself, or external storage). We're > not allowed to make assumptions about where these buffers are. Also, a > single ethernet frame can be fragmented across multiple mbufs in a list. > > So unless I'm mistaken, for each mbuf in an mbuf list, what we > have to do is this: > > - create a bus_dmamap_t for the data area in the mbuf using > bus_dmamap_create() > - do the physical to bus mapping with bus_dmamap_load() > - call bus_dmamap_sync() as needed (might handle copying if bounce > buffers are required) > - > - do post-DMA sync as needed (again, might require bounce copying) > - call bus_dmamap_unload() to un-do the bus mapping (which might free > bounce buffers if some were allocated by bus_dmamap_load()) > - destroy the bus_dmamap_t > > One memory region, one DMA map. It seems to me that you can't use a > single dmamap for multiple memory buffers, unless you make certain > assumptions about where in physical memory those buffers reside, and > I thought the idea of busdma was to provide a consistent, opaque API > so that you would not have to make any assumptions. > > Now if I've gotten any of this wrong, please tell me how I should be > doing it. Remember to show all work. I don't give partial credit, nor > do I grade on a curve. This is fine insofar as it goes, but there's nothing, I believe, that requires you to *create* a bus_dmamap_t each time you wish to map something and then destroy it when you unmap something. You might ask why one actually has the separate step from map creation and map load at all then. All the rest of the stuff for load/sync/sync/unload is fine. Using The Code (tm)- you can see that, for example, you can create a tag that describes all of the the addressable space your device can access, e.g.: if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim, BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1, BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) { isp_prt(isp, ISP_LOGERR, "cannot create a dma tag for control spaces"); free(isp->isp_xflist, M_DEVBUF); free(pci->dmaps, M_DEVBUF); return (1); } Then, for each possible transaction slot- if you have a device that has a fixed number of transactions that are possible (as many do), you can create maps ahead of time: for (i = 0; i < isp->isp_maxcmds; i++) { error = bus_dmamap_create(pci->parent_dmat, 0, &pci->dmaps[i]); if (error) { ... so that for each transaction that needs to be mapped, you can dma load it: bus_dmamap_t *dp; ... dp = &pci->dmaps[isp_handle_index(rq->req_handle)]; ... s = splsoftvm(); error = bus_dmamap_load(pci->parent_dmat, *dp, csio->data_ptr, csio->dxfer_len, eptr, mp, 0); ... which as part of the load process can sync it: dp = &pci->dmaps[isp_handle_index(rq->req_handle)]; if ((csio->ccb_h.flags & CAM_DIR_MASK) == CAM_DIR_IN) { bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_PREREAD); } else { bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_PREWRITE); } and when the transaction is done, you can sync and unload: static void isp_pci_dmateardown(struct ispsoftc *isp, XS_T *xs, u_int16_t handle) { struct isp_pcisoftc *pci = (struct isp_pcisoftc *)isp; bus_dmamap_t *dp = &pci->dmaps[isp_handle_index(handle)]; if ((xs->ccb_h.flags & CAM_DIR_MASK) == CAM_DIR_IN) { bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_POSTREAD); } else { bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_POSTWRITE); } bus_dmamap_unload(pci->parent_dmat, *dp); } ------------ So- my question still stands- from a performance point of view (Networking people *do* care about performance I believe, yes? :-))- if you don't need to create the map each time, wouldn't you rather not? So, the mbuf mapping code, which is cool to have, really might not need this? > > > The current suggestion is fine except that each platform might have a more > > > efficient, or even required, actual h/w mechanism for mapping mbufs. > > It might, but right now, it doesn't. All I have to work with is the > existing API. I'm not here to stick my fingers in it and change it all > around. I just want to add a bit of code on top of it so that I don't > have to go through quite so many contortions when I use the API in > network adapter drivers. This is not on point. This wasn't an API issue. The existing implementation is in fact maintained as platform specific code. I'm gently suggesting that you consider following suit because there may in fact *be* platform specifics in the future. Or don't. There aren't really any right now- so perhaps I'm overanticipating issues down the line where we have to atticize this file because we had to move all the functions to platform files. > > > > I'd also be a little concerned with the way you're overloading stuff > > > into mbuf.... > > I thought about this. Like it says in the comments, at the device driver > level, you're almost never going to be using some of the pointers in the > mbuf header. On the RX side, *we* (i.e. the driver) are allocating the > mbufs, so we can do whatever the heck we want with them until such time > as we hand them off to ether_input(), and by then we will have put things > back the way they were. For the TX side, by the time we get the mbufs > off the send queue, we always know we're going to have just an mbuf list > (and not an mbuf chain), and we're going to toss the mbufs once we're done > with them, so we can trample on certain things that we know don't matter > to the OS or network stack anymore. > > The alternatives are: > > - Allocate some extra space in the DMA descriptor structures for the > necessary bus_dmamap_t pointers. This is tricky with this particular > NIC, and a little awkward. > - Allocate my own private arrays of bus_dmamap_t that mirror the DMA > rings. This is yet more memory I need to allocate and free at device > attach and detach time. > > I've got space in the mbuf header. It's not being used. It's right > where I need it. Why not take advantage of it? Well- I'll really defer to you on this. Like I said- I'm shakier about it. Why don't we just allocate space in the pkthdr- or while we're at it, have a per-device pool allocator/free/pullup/dma_map vector as part of the pkthdr anyway- that might be of more long term interest anyway, no (e.g., for large MTU allocations so that pkts can be pooled per device- might as well do the DMA goop as part of this while you're at it). > > > Finally- why not make this an inline? > > Er... because that idea offended my delicate sensibilities? :) Stiffen your lip, and think of England. Stout lad! -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 22:53:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 66E2437B408; Mon, 20 Aug 2001 22:53:23 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f7L5rMI71828; Mon, 20 Aug 2001 22:53:22 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 20 Aug 2001 22:53:06 -0700 (PDT) From: Matthew Jacob Reply-To: To: Bill Paul Cc: , Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: <20010820223007.I39850-100000@wonky.feral.com> Message-ID: <20010820225225.G39850-100000@wonky.feral.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 Correction. This sample: > > if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim, > BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1, > BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) { > isp_prt(isp, ISP_LOGERR, > "cannot create a dma tag for control spaces"); > free(isp->isp_xflist, M_DEVBUF); > free(pci->dmaps, M_DEVBUF); > return (1); > } > Should have been: if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, lim + 1, 255, lim, 0, &pcs->parent_dmat) != 0) { device_printf(dev, "could not create master dma tag\n"); free(isp->isp_param, M_DEVBUF); free(pcs, M_DEVBUF); return (ENXIO); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 23:23:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8930137B410; Mon, 20 Aug 2001 23:23:40 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id f7L6NdY90348; Tue, 21 Aug 2001 00:23:39 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200108210623.f7L6NdY90348@aslan.scsiguy.com> To: wpaul@FreeBSD.ORG (Bill Paul) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: Your message of "Mon, 20 Aug 2001 17:06:30 PDT." <20010821000630.92CF937B406@hub.freebsd.org> Date: Tue, 21 Aug 2001 00:23:39 -0600 From: "Justin T. Gibbs" 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 >Every hear the phrase "you get what you pay for?" The API isn't all that >clear, and we don't have a man page or document that describes in detail >how to use it properly. Rather than whining about that, I decided to >tinker with it and Use The Source, Luke (tm). This is the result. Fair enough. >My understanding is that you need a dmamap for every buffer that you want >to map into bus space. You need one dmamap for each independantly manageable mapping. A single mapping may result in a long list of segments, regardless of whether you have a single KVA buffer or multiple KVA buffers that might contribute to the mapping. >Each mbuf has a single data buffer associated with >it (either the data area in the mbuf itself, or external storage). We're >not allowed to make assumptions about where these buffers are. Also, a >single ethernet frame can be fragmented across multiple mbufs in a list. > >So unless I'm mistaken, for each mbuf in an mbuf list, what we >have to do is this: > >- create a bus_dmamap_t for the data area in the mbuf using > bus_dmamap_create() Creating a dmamap, depending on the architecture, could be expensive. You really want to create them in advance (or pool them), with at most one dmamap per concurrent transaction you support in your driver. >- do the physical to bus mapping with bus_dmamap_load() bus_dmamap_load() only understands how to map a single buffer. You will have to pull pieces of bus_dmamap_load into a new function (or create inlines for common bits) to do this correctly. The algorithm goes something like this: foreach mbuf in the mbuf chain to load /* * Parse this contiguous piece of KVA into * its bus space regions. */ foreach "bus space" discontiguous region if (too_many_segs) return (error); Add new S/G element With the added complications of deferring the mapping if we're out of space, issuing the callback, etc. >- call bus_dmamap_sync() as needed (might handle copying if bounce > buffers are required) >- >- do post-DMA sync as needed (again, might require bounce copying) >- call bus_dmamap_unload() to un-do the bus mapping (which might free > bounce buffers if some were allocated by bus_dmamap_load()) >- destroy the bus_dmamap_t Chances are you are going to use the map again soon, so destroying it on every transaction is a waste. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 20 23:30:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 9D4BE37B40C; Mon, 20 Aug 2001 23:30:26 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id f7L6UNY90382; Tue, 21 Aug 2001 00:30:23 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200108210630.f7L6UNY90382@aslan.scsiguy.com> To: mjacob@feral.com Cc: Bill Paul , hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: Your message of "Mon, 20 Aug 2001 22:53:06 PDT." <20010820225225.G39850-100000@wonky.feral.com> Date: Tue, 21 Aug 2001 00:30:23 -0600 From: "Justin T. Gibbs" 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 > >Correction. > >This sample: >> >> if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim, >> BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1, >> BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) { >> isp_prt(isp, ISP_LOGERR, >> "cannot create a dma tag for control spaces"); >> free(isp->isp_xflist, M_DEVBUF); >> free(pci->dmaps, M_DEVBUF); >> return (1); >> } >> You'll need to change the number of segments to match the max supported by the card (or the max you will ever need). This example made me realize that the bounce code doesn't deal with multiple segments being copied into a single page (i.e. tracking and using remaining free space in a page already allocated for bouncing for a single map). I'll have to break loose some time to fix that. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 0:10:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id C927537B40B; Tue, 21 Aug 2001 00:10:27 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f7L7AOn13309; Tue, 21 Aug 2001 09:10:25 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: obrien@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: Re: header polution In-Reply-To: Your message of "Mon, 20 Aug 2001 17:57:43 PDT." <20010820175743.A33795@dragon.nuxi.com> Date: Tue, 21 Aug 2001 09:10:24 +0200 Message-ID: <13307.998377824@critter> 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 <20010820175743.A33795@dragon.nuxi.com>, "David O'Brien" writes: >When compiling the `dict' port, one gets: > > In file included from /usr/include/machine/signal.h:54, > from /usr/include/sys/signal.h:178, > from /usr/include/signal.h:44, > from dict.h:33, > from clientparse.y:25: > /usr/include/machine/trap.h:105: warning: `T_USER' redefined > >This seems very wrong. Can't we rename "T_USER" in the kernel to >"_T_USER", or wrap it in _KERNEL? The comment in machine/signal.h(x86) >says: > > #include /* codes for SIGILL, SIGFPE */ > >but does that mean we must expose the entire contents of trap.h to >userland? The problem is T_ is very common in lex source. We most certainly shouldn't. Everything but the needed bits should be #ifdef KERNEL. -- 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 Tue Aug 21 1:35:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id A5FB637B40C; Tue, 21 Aug 2001 01:35:38 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 21 Aug 2001 09:35:35 +0100 (BST) To: walter@pelissero.org Cc: John Baldwin , net@FreeBSD.org, hackers@FreeBSD.org, Andre Albsmeier , Warner Losh Subject: Re: 4.4-RC NFS panic In-reply-to: Your message of "Tue, 21 Aug 2001 00:38:31 BST." <15233.40823.749512.643101@hyde.lpds.sublink.org> X-Request-Do: Date: Tue, 21 Aug 2001 09:35:34 +0100 From: David Malone Message-ID: <200108210935.aa87782@salmon.maths.tcd.ie> 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've just done a further test. I've mounted a directory tree from > Vaio to Vaio using localhost (lo driver) and the test has run > smoothly. So chances would be good the bug is in the ep driver. > Unfortunately... Andre Albsmeier, who's seeing various network problems, is using the xe driver (also PCMCIA I think), but the problems go away if he uses an Etherexpress card on the PCI bus of the same machine. It seems unlikely to be PCMCIA related ('cos it has nothing to do with the networking itself) it may just be triggered in machines with slower networking. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 2: 2:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 3C5A437B40F; Tue, 21 Aug 2001 02:02:41 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f7L924b20344; Tue, 21 Aug 2001 11:02:04 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail1.siemens.de (8.11.4/8.11.4) with ESMTP id f7L923708772; Tue, 21 Aug 2001 11:02:04 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.11.3/8.11.3) id f7L923K51581; Date: Tue, 21 Aug 2001 11:02:03 +0200 From: Andre Albsmeier To: David Malone Cc: walter@pelissero.org, John Baldwin , net@FreeBSD.org, hackers@FreeBSD.org, Andre Albsmeier , Warner Losh Subject: Re: 4.4-RC NFS panic Message-ID: <20010821110203.A24141@curry.mchp.siemens.de> References: <15233.40823.749512.643101@hyde.lpds.sublink.org> <200108210935.aa87782@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108210935.aa87782@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Tue, Aug 21, 2001 at 09:35:34AM +0100 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike 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, 21-Aug-2001 at 09:35:34 +0100, David Malone wrote: > > I've just done a further test. I've mounted a directory tree from > > Vaio to Vaio using localhost (lo driver) and the test has run > > smoothly. So chances would be good the bug is in the ep driver. > > Unfortunately... > > Andre Albsmeier, who's seeing various network problems, is using > the xe driver (also PCMCIA I think), but the problems go away if > he uses an Etherexpress card on the PCI bus of the same machine. As I wrote in my PR (#29845), my problems also happen with the 3C589 which uses the ep driver. So we can sum up to: 1.) Intel Etherexpress PRO/100 PCMCIA (xe driver) crashes 2.) 3Com 589D EtherLink III PCMCIA (ep driver) crashes 3.) Intel Etherexpress PRO/100+ PCI Card (fxp driver) works perfectly -Andre > > It seems unlikely to be PCMCIA related ('cos it has nothing to do > with the networking itself) it may just be triggered in machines > with slower networking. > > David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 2: 7:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A910A37B401; Tue, 21 Aug 2001 02:07:35 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7L97Xq38200; Tue, 21 Aug 2001 03:07:34 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7L97XW64198; Tue, 21 Aug 2001 03:07:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108210907.f7L97XW64198@harmony.village.org> To: Andre Albsmeier Subject: Re: 4.4-RC NFS panic Cc: David Malone , walter@pelissero.org, John Baldwin , net@FreeBSD.org, hackers@FreeBSD.org In-reply-to: Your message of "Tue, 21 Aug 2001 11:02:03 +0200." <20010821110203.A24141@curry.mchp.siemens.de> References: <20010821110203.A24141@curry.mchp.siemens.de> <15233.40823.749512.643101@hyde.lpds.sublink.org> <200108210935.aa87782@salmon.maths.tcd.ie> Date: Tue, 21 Aug 2001 03:07:33 -0600 From: Warner Losh 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 <20010821110203.A24141@curry.mchp.siemens.de> Andre Albsmeier writes: : As I wrote in my PR (#29845), my problems also happen with : the 3C589 which uses the ep driver. So we can sum up to: : : 1.) Intel Etherexpress PRO/100 PCMCIA (xe driver) crashes : 2.) 3Com 589D EtherLink III PCMCIA (ep driver) crashes : 3.) Intel Etherexpress PRO/100+ PCI Card (fxp driver) works perfectly Interesting. I'm not sure what to make of this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 2:14:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from synology.com (dns1.synology.com [202.173.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 878B737B406 for ; Tue, 21 Aug 2001 02:14:28 -0700 (PDT) (envelope-from rexluo@synology.com) Received: from synology.com (IDENT:nobody@localhost [127.0.0.1]) by synology.com (8.9.3/8.9.3) with SMTP id RAA02022 for hackers@FreeBSD.ORG; Tue, 21 Aug 2001 17:14:51 +0800 Date: Tue, 21 Aug 2001 17:14:51 +0800 Message-Id: <200108210914.RAA02022@synology.com> To: hackers@FreeBSD.ORG Subject: unpaired splbio() and splx() in vfs_unmountall() From: Rex Luo X-Mailer: TWIG 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 Dear, I modifid kernel to write to disk directly after unmount all mounted filesystem in boot() kern/kern_shutdown.c. However, I found that my IO requests wouldn't have callback from device interrupt routine. I traced the codes and use gdb to find something out. The interesting is after execute vfs_unmountall() -> dounmount() -> ffs_unmount() -> ffs_flushfiles() -> vflush()-> ??? the interrupt mask is set by splbio() without splx(), therefore, all my following requests cannot return. Notice that, the situation only happens after heavy IO, for example: cp 30 files at the same time. I use spl0() to solve the prolbem, but I think it's not the right way to do that. Can anyone provide some clues or suggestions. Thanks -- Rex Luo Tel : 886-2-25521814 Ext. 824 Fax : 886-2-25521824 e-mail : rexluo@synology.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 2:25:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 705D737B412; Tue, 21 Aug 2001 02:25:19 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f7L9P5b03494; Tue, 21 Aug 2001 11:25:05 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.11.4/8.11.4) with ESMTP id f7L9P4n10627; Tue, 21 Aug 2001 11:25:05 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.11.3/8.11.3) id f7L9P4K51719; Date: Tue, 21 Aug 2001 11:25:04 +0200 From: Andre Albsmeier To: Warner Losh Cc: Andre Albsmeier , David Malone , walter@pelissero.org, John Baldwin , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic Message-ID: <20010821112504.A24304@curry.mchp.siemens.de> References: <20010821110203.A24141@curry.mchp.siemens.de> <15233.40823.749512.643101@hyde.lpds.sublink.org> <200108210935.aa87782@salmon.maths.tcd.ie> <20010821110203.A24141@curry.mchp.siemens.de> <200108210907.f7L97XW64198@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108210907.f7L97XW64198@harmony.village.org>; from imp@harmony.village.org on Tue, Aug 21, 2001 at 03:07:33AM -0600 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike 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, 21-Aug-2001 at 03:07:33 -0600, Warner Losh wrote: > In message <20010821110203.A24141@curry.mchp.siemens.de> Andre Albsmeier writes: > : As I wrote in my PR (#29845), my problems also happen with > : the 3C589 which uses the ep driver. So we can sum up to: > : > : 1.) Intel Etherexpress PRO/100 PCMCIA (xe driver) crashes > : 2.) 3Com 589D EtherLink III PCMCIA (ep driver) crashes > : 3.) Intel Etherexpress PRO/100+ PCI Card (fxp driver) works perfectly > > Interesting. I'm not sure what to make of this. So do I. Ian Dowse already sent me a program to inspect the mbufs in the crashdumps. I don't know a lot about mbufs but the output appears really hosed... I will try it again using another PCMICA card I just got... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 3:14:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from algol.vtrip-ltd.com (algol.vtrip-ltd.com [139.91.200.19]) by hub.freebsd.org (Postfix) with ESMTP id 0643437B410 for ; Tue, 21 Aug 2001 03:14:18 -0700 (PDT) (envelope-from verigak@vtrip-ltd.com) Received: from verigak (helo=localhost) by algol.vtrip-ltd.com with local-esmtp (Exim 3.12 #1 (Debian)) id 15Z8Vg-0006YY-00 for ; Tue, 21 Aug 2001 13:11:48 +0300 Date: Tue, 21 Aug 2001 13:11:48 +0300 (EEST) From: Giorgos Verigakis To: Subject: Zope's performance issues 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 Hello, I'm using Zope application server (www.zope.org) on FreeBSD and I'm experiencing some serious performance issues. Since I hadn't noticed any problems at the past with Linux, I did some benchmarks to investigate it a little. I've written a small program that connects to Zope and tries to retrieve a non-existant URL (source code appended). While Linux performed almost linearly depending on the number of hits/sec, FreeBSD (and OpenBSD) performed exponential. I allready sent a mail to the zope-list but I did not get much info. Since Zope is a threaded application I was wondering maybe it was related with the thread implementation (the scheduling maybe?) I did the following experiment: I installed a binary distribution of python-1.5.2 (pkg_add or apt-get) and I compiled Zope-2.3.3+HotFix from sources. I started running the previous program and after about 1000 hits (when the server would be a bit loaded) I reloaded a fairly complex page and measured the time it gets to finish. The results are below: +---------------------+------------+---------------+-------------+ | OS | Hit Rate* | Real hit rate | Reload time | | | (hits/sec) | (hits/sec) | (sec) | +---------------------+------------+---------------+-------------+ | | 30 | 20 | 13 | | Linux debian 2.2.19 | 50 | 33 | 16 | | | 100 | 38 | 16 | +---------------------+------------+---------------+-------------+ | | 30 | 20 | 10 | | FreeBSD 4.3-Release | 50 | 33 | 23 | | | 100 | 40 | 100 | +---------------------+------------+---------------+-------------+ | | 30 | 20 | 10 | | OpenBSD 2.9-Release | 50 | 33 | 15 | | | 100 | 50 | 285 | +---------------------+------------+---------------+-------------+ *The hit rate is the one passed as an argument to the program, while real hit rate was calculated according to Zope's log file. All tests were ran on the same computer, a 600MHz Celeron with 192MB RAM These tests were ran using the default content. When I use a real (more heavy) content I even get time-outs when I try to access some pages. Has anyone in this list had any previous experience with zope? and how do tou explain the big differences between the OSs? Thank you in advance Giorgos Verigakis ------------------ 8< ------------------ #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct sockaddr_in sa; struct hostent *hp; int s; int i, t, len; unsigned long sleeptime; char request[128]; char *url="/foo"; if (argc != 4) { printf("Usage: %s \n", argv[0]); printf("rate in hits/sec\n"); exit(1); } if ((hp = gethostbyname(argv[1])) == NULL) { printf("error looking up host\n"); exit(1); } sprintf(request, "GET %s HTTP/1.0\015\012\015\012", url); len = strlen(request); sleeptime = (1 / atof(argv[3])) * 1000000; bzero(&sa, sizeof(sa)); bcopy(hp->h_addr, (char *)&sa.sin_addr, hp->h_length); sa.sin_family = hp->h_addrtype; sa.sin_port = htons(atoi(argv[2])); for (i = 0;; i++) { if (( s = socket(hp->h_addrtype, SOCK_STREAM, 0)) < 0) { printf("Socket error\n"); continue; } if (connect(s, (struct sockaddr *) &sa, sizeof sa) < 0) { printf("Connection error\n"); close(s); continue; } t = write(s, request, len); printf("i=%d: %d bytes\n", i, t); usleep(sleeptime); close(s); } } ------------------ 8< ------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 3:24:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 7CA6037B414; Tue, 21 Aug 2001 03:24:41 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id f7LAOVc19929; Tue, 21 Aug 2001 12:24:31 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id f7LAOVw35731842; Tue, 21 Aug 2001 12:24:31 +0200 (MEST) Received: (from localhost) by curry.mchp.siemens.de (8.11.3/8.11.3) id f7LAOUK51987; Date: Tue, 21 Aug 2001 12:24:30 +0200 From: Andre Albsmeier To: Warner Losh Cc: Andre Albsmeier , David Malone , walter@pelissero.org, John Baldwin , net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: 4.4-RC NFS panic Message-ID: <20010821122430.A25855@curry.mchp.siemens.de> References: <20010821110203.A24141@curry.mchp.siemens.de> <15233.40823.749512.643101@hyde.lpds.sublink.org> <200108210935.aa87782@salmon.maths.tcd.ie> <20010821110203.A24141@curry.mchp.siemens.de> <200108210907.f7L97XW64198@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108210907.f7L97XW64198@harmony.village.org>; from imp@harmony.village.org on Tue, Aug 21, 2001 at 03:07:33AM -0600 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike 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, 21-Aug-2001 at 03:07:33 -0600, Warner Losh wrote: > In message <20010821110203.A24141@curry.mchp.siemens.de> Andre Albsmeier writes: > : As I wrote in my PR (#29845), my problems also happen with > : the 3C589 which uses the ep driver. So we can sum up to: > : > : 1.) Intel Etherexpress PRO/100 PCMCIA (xe driver) crashes > : 2.) 3Com 589D EtherLink III PCMCIA (ep driver) crashes > : 3.) Intel Etherexpress PRO/100+ PCI Card (fxp driver) works perfectly > > Interesting. I'm not sure what to make of this. We can now add: 4.) D-Link DFE-650 PCMCIA (ed driver) freezes :-( Warner, I have seen your mails regarding pcic-44rc1.diff.1. My box has a TI PCI-1225 chip... I will try the patch... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 4:33:27 2001 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 5643C37B415; Tue, 21 Aug 2001 04:33:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.137.2.Dial1.SanJose1.Level3.net [209.245.137.2]) by snipe.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id EAA10582; Tue, 21 Aug 2001 04:33:00 -0700 (PDT) Message-ID: <3B824716.2398B45A@mindspring.com> Date: Tue, 21 Aug 2001 04:33:42 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Leo Bicknell , Matt Dillon , hackers@FreeBSD.ORG, murray@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Recommendation for minor KVM adjustments for the release References: <20010819013443.3710F38FD@overcee.netplex.com.au> 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: > No. I have a machine with 6GB in it waiting for finishing the PAE > tweaks. Are you actually going ahead with the PAE support? Will this be a compile-time option, so that it can be turned off? I considered doing the same, about 4 months ago but it's not like I could use the additional memory for mbufs, sockets, or other useful kernel structures, so I bailed on completing it. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 6: 8:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id ADE0737B409; Tue, 21 Aug 2001 06:08:11 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from 1-083.ctame701-1.telepar.net.br (1-083.ctame701-1.telepar.net.br [200.181.137.83]) by netbank.com.br (Postfix) with ESMTP id 12F5B46809; Tue, 21 Aug 2001 10:06:42 -0300 (BRST) Received: from localhost ([IPv6:::ffff:127.0.0.1]:25984 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Tue, 21 Aug 2001 10:07:52 -0300 Date: Tue, 21 Aug 2001 10:07:33 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Terry Lambert Cc: Peter Wemm , Leo Bicknell , Matt Dillon , , , Subject: Re: Recommendation for minor KVM adjustments for the release In-Reply-To: <3B824716.2398B45A@mindspring.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.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 On Tue, 21 Aug 2001, Terry Lambert wrote: > Peter Wemm wrote: > > No. I have a machine with 6GB in it waiting for finishing the PAE > > tweaks. > > Are you actually going ahead with the PAE support? > > Will this be a compile-time option, so that it can be > turned off? It better be because the thing doubles page table overhead and slows down the machine by about 6%. Then again, it beats having to leave the top 12GB unused ;) Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to aardvark@nl.linux.org (spam digging piggy) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 6:11:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 015CF37B406 for ; Tue, 21 Aug 2001 06:11:28 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 19117 invoked by uid 3193); 21 Aug 2001 13:11:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Aug 2001 13:11:26 -0000 Date: Tue, 21 Aug 2001 09:11:26 -0400 (EDT) From: Mike Silbersack X-Sender: To: Giorgos Verigakis Cc: Subject: Re: Zope's performance issues 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 Tue, 21 Aug 2001, Giorgos Verigakis wrote: > Hello, I'm using Zope application server (www.zope.org) on FreeBSD > and I'm experiencing some serious performance issues. > Since I hadn't noticed any problems at the past with Linux, I did > some benchmarks to investigate it a little. > > I've written a small program that connects to Zope and tries to > retrieve a non-existant URL (source code appended). While Linux > performed almost linearly depending on the number of hits/sec, > FreeBSD (and OpenBSD) performed exponential. I allready sent > a mail to the zope-list but I did not get much info. > Since Zope is a threaded application I was wondering maybe it > was related with the thread implementation (the scheduling maybe?) I suspect that the reload time spiking is due to our initial sequence number generation scheme, which is currently shared with OpenBSD. This will be changing RSN, which will likely change how your benchmarks look. (They should look better after the change.) I'm curious about the reload time, though. Is it really in seconds? What is it measuring? Oops, I just noticed the source below... I'll read it and try out the test to see if my above theory is correct later today. 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 Tue Aug 21 6:25:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from algol.vtrip-ltd.com (algol.vtrip-ltd.com [139.91.200.19]) by hub.freebsd.org (Postfix) with ESMTP id 6481C37B40D for ; Tue, 21 Aug 2001 06:25:51 -0700 (PDT) (envelope-from verigak@vtrip-ltd.com) Received: from verigak (helo=localhost) by algol.vtrip-ltd.com with local-esmtp (Exim 3.12 #1 (Debian)) id 15ZBUb-0006oD-00; Tue, 21 Aug 2001 16:22:53 +0300 Date: Tue, 21 Aug 2001 16:22:53 +0300 (EEST) From: Giorgos Verigakis To: Mike Silbersack Cc: Subject: Re: Zope's performance issues 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 Tue, 21 Aug 2001, Mike Silbersack wrote: > > On Tue, 21 Aug 2001, Giorgos Verigakis wrote: > > > Hello, I'm using Zope application server (www.zope.org) on FreeBSD > > and I'm experiencing some serious performance issues. > > Since I hadn't noticed any problems at the past with Linux, I did > > some benchmarks to investigate it a little. > > > > I've written a small program that connects to Zope and tries to > > retrieve a non-existant URL (source code appended). While Linux > > performed almost linearly depending on the number of hits/sec, > > FreeBSD (and OpenBSD) performed exponential. I allready sent > > a mail to the zope-list but I did not get much info. > > Since Zope is a threaded application I was wondering maybe it > > was related with the thread implementation (the scheduling maybe?) > > I suspect that the reload time spiking is due to our initial sequence > number generation scheme, which is currently shared with OpenBSD. This > will be changing RSN, which will likely change how your benchmarks look. > (They should look better after the change.) I don't understand. How is it related with the initial sequence number? > > I'm curious about the reload time, though. Is it really in seconds? What > is it measuring? Yes it's in seconds. What I wanted to measure was the time a page needs to be loaded, because the results I was getting were unexpectable. > > Oops, I just noticed the source below... I'll read it and try out the test > to see if my above theory is correct later today. > > 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 Tue Aug 21 7:37:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id E6A8337B401 for ; Tue, 21 Aug 2001 07:37:49 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from madman.nectar.com (madman.nectar.com [10.0.1.111]) by gw.nectar.com (Postfix) with ESMTP id 4C85788A for ; Tue, 21 Aug 2001 09:37:49 -0500 (CDT) Received: (from nectar@localhost) by madman.nectar.com (8.11.3/8.11.3) id f7LEbnp25453 for hackers@freebsd.org; Tue, 21 Aug 2001 09:37:49 -0500 (CDT) (envelope-from nectar) Date: Tue, 21 Aug 2001 09:37:49 -0500 From: "Jacques A. Vidrine" To: hackers@freebsd.org Subject: inet6 address host <-> network order Message-ID: <20010821093749.A25444@madman.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Url: http://www.nectar.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 What's the most portable way of converting an IPv6 address from host to network order? Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 8: 7: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id D535537B403 for ; Tue, 21 Aug 2001 08:07:01 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from madman.nectar.com (madman.nectar.com [10.0.1.111]) by gw.nectar.com (Postfix) with ESMTP id 345CF4C4 for ; Tue, 21 Aug 2001 10:07:01 -0500 (CDT) Received: (from nectar@localhost) by madman.nectar.com (8.11.3/8.11.3) id f7LF71926666 for hackers@freebsd.org; Tue, 21 Aug 2001 10:07:01 -0500 (CDT) (envelope-from nectar) Date: Tue, 21 Aug 2001 10:07:00 -0500 From: "Jacques A. Vidrine" To: hackers@freebsd.org Subject: Re: inet6 address host <-> network order Message-ID: <20010821100700.B25444@madman.nectar.com> References: <20010821093749.A25444@madman.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010821093749.A25444@madman.nectar.com>; from n@nectar.com on Tue, Aug 21, 2001 at 09:37:49AM -0500 X-Url: http://www.nectar.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 On Tue, Aug 21, 2001 at 09:37:49AM -0500, Jacques A. Vidrine wrote: > What's the most portable way of converting an IPv6 address from host > to network order? Nothing like following up your own post. RFC 2553 indicates that the IPv6 address is stored in the `struct in6_addr' in network byte order, so there shouldn't be any need to swap bytes. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 8:55: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from algol.vtrip-ltd.com (algol.vtrip-ltd.com [139.91.200.19]) by hub.freebsd.org (Postfix) with ESMTP id 5C4C437B403 for ; Tue, 21 Aug 2001 08:54:59 -0700 (PDT) (envelope-from verigak@vtrip-ltd.com) Received: from verigak (helo=localhost) by algol.vtrip-ltd.com with local-esmtp (Exim 3.12 #1 (Debian)) id 15ZDpR-0006yh-00 for ; Tue, 21 Aug 2001 18:52:33 +0300 Date: Tue, 21 Aug 2001 18:52:33 +0300 (EEST) From: Giorgos Verigakis To: Subject: Zope's performance issues (cont.) 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 To check if it was indeed a thread problem, I repeated my tests using Zope-2.4.0 and python 2.1.1 First I did a default python compilation (using libc_r) and then using pth (GNU portable threads) Using the program I sent on my previous email and a hit rate of 100 I got libc_r: 243 sec, 28 real hits/sec pth: 15 sec, 36 real hits/sec So, I guess there is some problem on libc_r Giorgos PS: I did the same on OpenBSD and had similar results To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 9: 7:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id 8914B37B408 for ; Tue, 21 Aug 2001 09:07:37 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost ([127.0.0.1] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 15ZECj-0000BV-00; Tue, 21 Aug 2001 10:16:37 -0600 Message-ID: <3B828965.C75C7639@softweyr.com> Date: Tue, 21 Aug 2001 10:16:37 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dan Cox Cc: freebsd-hackers@freebsd.org Subject: Re: wireless nic recommendations References: <004301c127bd$c4dc5200$0100a8c0@network> 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 Dan Cox wrote: > > Here is my situation. My house can't get DSL or cable. Our neighbors who > live 20-30 feet away do have DSL and have agreed to share the connection. To > make a long story short we have successfully set up a wireless LAN for the > two houses, we've been using a windows laptop to test the connection. I > would like to find out what wireless NIC's are compatible with freeBSD or > some recommendations. I have a wireless ISP, my connection to the internet is a Cisco/Aironet: an0: port 0x6700-0x673f,0x6600-0x667f mem 0xe1001000- 0xe100107f irq 12 at device 13.0 on pci0 I've had no problems with this card, it is currently reaching about 6.5 miles without an amplifier, using a 24 dB "fruit basket" antenna on the roof of my house. The throughput is sufficient to hit my 300 Kbps band- width limitation enforced at the access point 24x7. The initial speed tests performed by the ISP showed speed consistent above 1,000 Kbps. You should have little problem with speed going between two houses. The Cisco cards are pretty expensive compared to other brands. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 9:24:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.RWTH-Aachen.DE [137.226.46.168]) by hub.freebsd.org (Postfix) with ESMTP id AAD6137B401 for ; Tue, 21 Aug 2001 09:24:11 -0700 (PDT) (envelope-from kuku@gilberto.physik.rwth-aachen.de) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.11.1/8.9.3) id f7LGOAA46469 for hackers@freebsd.org; Tue, 21 Aug 2001 18:24:10 +0200 (CEST) (envelope-from kuku) Date: Tue, 21 Aug 2001 18:24:10 +0200 (CEST) From: Christoph Kukulies Message-Id: <200108211624.f7LGOAA46469@gilberto.physik.rwth-aachen.de> To: hackers@freebsd.org Subject: notebook HW 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 Is there a maiing list that deal especially with FreeBSD on notebook issues? If not, could it be created or is this covered by another list? (hardware?) -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 9:27:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (dialmess.nanolink.com [217.75.135.246]) by hub.freebsd.org (Postfix) with SMTP id 456D337B403 for ; Tue, 21 Aug 2001 09:27:30 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 1173 invoked by uid 1000); 21 Aug 2001 16:26:05 -0000 Date: Tue, 21 Aug 2001 19:26:05 +0300 From: Peter Pentchev To: Christoph Kukulies Cc: hackers@freebsd.org Subject: Re: notebook HW Message-ID: <20010821192605.B642@ringworld.oblivion.bg> Mail-Followup-To: Christoph Kukulies , hackers@freebsd.org References: <200108211624.f7LGOAA46469@gilberto.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108211624.f7LGOAA46469@gilberto.physik.rwth-aachen.de>; from kuku@gilberto.physik.rwth-aachen.de on Tue, Aug 21, 2001 at 06:24:10PM +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 Tue, Aug 21, 2001 at 06:24:10PM +0200, Christoph Kukulies wrote: > Is there a maiing list that deal especially with FreeBSD on notebook > issues? > > If not, could it be created or is this covered by another list? (hardware?) Try freebsd-mobile@FreeBSD.org :) G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 9:27:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from temphost.dragondata.com (temphost.dragondata.com [63.167.131.128]) by hub.freebsd.org (Postfix) with ESMTP id EDF6737B403 for ; Tue, 21 Aug 2001 09:27:45 -0700 (PDT) (envelope-from toasty@temphost.dragondata.com) Received: (from toasty@localhost) by temphost.dragondata.com (8.11.3/8.11.3) id f7LGRdI67207 for hackers@freebsd.org; Tue, 21 Aug 2001 11:27:39 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <200108211627.f7LGRdI67207@temphost.dragondata.com> Subject: XMM[0-7] preserved across context switch? To: hackers@freebsd.org Date: Tue, 21 Aug 2001 11:27:38 -0500 (CDT) X-Mailer: ELM [version 2.5 PL5] 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 A quick peek at swtch.s seems to show that the SSE registers (XMM0-7) aren't being preserved across context switches. Am I missing somewhere that's doing this, or are they really not being saved now? -- Kevin Day toasty@dragondata.com - kevin@stileproject.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 10: 1: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.RWTH-Aachen.DE [137.226.46.168]) by hub.freebsd.org (Postfix) with ESMTP id 618C537B40B for ; Tue, 21 Aug 2001 10:00:58 -0700 (PDT) (envelope-from kuku@gilberto.physik.rwth-aachen.de) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.11.1/8.9.3) id f7LH0ux46741; Tue, 21 Aug 2001 19:00:56 +0200 (CEST) (envelope-from kuku) Date: Tue, 21 Aug 2001 19:00:56 +0200 From: Christoph Kukulies To: Christoph Kukulies , hackers@freebsd.org Subject: Re: notebook HW Message-ID: <20010821190056.A46686@gil.physik.rwth-aachen.de> References: <200108211624.f7LGOAA46469@gilberto.physik.rwth-aachen.de> <20010821192605.B642@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010821192605.B642@ringworld.oblivion.bg>; from roam@ringlet.net on Tue, Aug 21, 2001 at 07:26:05PM +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 Tue, Aug 21, 2001 at 07:26:05PM +0300, Peter Pentchev wrote: > On Tue, Aug 21, 2001 at 06:24:10PM +0200, Christoph Kukulies wrote: > > Is there a maiing list that deal especially with FreeBSD on notebook > > issues? > > > > If not, could it be created or is this covered by another list? (hardware?) > > Try freebsd-mobile@FreeBSD.org :) Argh. How could I overlook that :-) Thanks. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 10:45:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9348C37B409; Tue, 21 Aug 2001 10:45:18 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7LHjDq39709; Tue, 21 Aug 2001 11:45:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7LHjCW66969; Tue, 21 Aug 2001 11:45:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108211745.f7LHjCW66969@harmony.village.org> To: David Malone Subject: Re: 4.4-RC NFS panic Cc: walter@pelissero.org, John Baldwin , net@FreeBSD.ORG, hackers@FreeBSD.ORG, Andre Albsmeier In-reply-to: Your message of "Tue, 21 Aug 2001 09:35:34 BST." <200108210935.aa87782@salmon.maths.tcd.ie> References: <200108210935.aa87782@salmon.maths.tcd.ie> Date: Tue, 21 Aug 2001 11:45:12 -0600 From: Warner Losh 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 <200108210935.aa87782@salmon.maths.tcd.ie> David Malone writes: : Andre Albsmeier, who's seeing various network problems, is using : the xe driver (also PCMCIA I think), but the problems go away if : he uses an Etherexpress card on the PCI bus of the same machine. : : It seems unlikely to be PCMCIA related ('cos it has nothing to do : with the networking itself) it may just be triggered in machines : with slower networking. After talking with Ian Dowse, I think that we've hammered out what may cause this. Basically, the problem is code in net doing splnet() -> pcic_pci_intr -> netcard_intr -> network code. And we've interrupted the critical section, broken all kinds of invariants. Warner P.S. I think that with Ian's other interrupt changes, we can do the following w/o problems. This should fix the network problems, I think. Index: pcic_pci.c =================================================================== RCS file: /cache/ncvs/src/sys/pccard/pcic_pci.c,v retrieving revision 1.54.2.7 diff -u -r1.54.2.7 pcic_pci.c --- pcic_pci.c 2001/08/21 09:06:25 1.54.2.7 +++ pcic_pci.c 2001/08/21 17:18:06 @@ -515,15 +515,6 @@ * in the CD change. */ sp->getb(sp, PCIC_STAT_CHG); - - /* - * If we have a card in the slot with an interrupt handler, then - * call it. Note: This means that each card can have at most one - * interrupt handler for it. Since multifunction cards aren't - * supported, this shouldn't cause a problem in practice. - */ - if (sc->cd_present && sp->intr != NULL) - sp->intr(sp->argp); } /* @@ -784,36 +775,6 @@ return (0); } -static int -pcic_pci_setup_intr(device_t dev, device_t child, struct resource *irq, - int flags, driver_intr_t *intr, void *arg, void **cookiep) -{ - struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev); - struct pcic_slot *sp = &sc->slots[0]; - - if (sp->intr) { - device_printf(dev, -"Interrupt already established, possible multiple attach bug.\n"); - return (EINVAL); - } - sp->intr = intr; - sp->argp = arg; - *cookiep = sc; - return (0); -} - -static int -pcic_pci_teardown_intr(device_t dev, device_t child, struct resource *irq, - void *cookie) -{ - struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev); - struct pcic_slot *sp = &sc->slots[0]; - - sp->intr = NULL; - sp->argp = NULL; - return (0); -} - static device_method_t pcic_pci_methods[] = { /* Device interface */ DEVMETHOD(device_probe, pcic_pci_probe), @@ -829,8 +790,8 @@ DEVMETHOD(bus_release_resource, bus_generic_release_resource), DEVMETHOD(bus_activate_resource, pcic_activate_resource), DEVMETHOD(bus_deactivate_resource, pcic_deactivate_resource), - DEVMETHOD(bus_setup_intr, pcic_pci_setup_intr), - DEVMETHOD(bus_teardown_intr, pcic_pci_teardown_intr), + DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), + DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr), /* Card interface */ DEVMETHOD(card_set_res_flags, pcic_set_res_flags), To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 10:47:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 4423537B407 for ; Tue, 21 Aug 2001 10:47:12 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 21 Aug 2001 18:47:11 +0100 (BST) Date: Tue, 21 Aug 2001 18:47:10 +0100 From: David Malone To: Kevin Day Cc: hackers@freebsd.org Subject: Re: XMM[0-7] preserved across context switch? Message-ID: <20010821184710.A23874@walton.maths.tcd.ie> References: <200108211627.f7LGRdI67207@temphost.dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108211627.f7LGRdI67207@temphost.dragondata.com>; from toasty@temphost.dragondata.com on Tue, Aug 21, 2001 at 11:27:38AM -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 Tue, Aug 21, 2001 at 11:27:38AM -0500, Kevin Day wrote: > A quick peek at swtch.s seems to show that the SSE registers (XMM0-7) aren't > being preserved across context switches. Am I missing somewhere that's doing > this, or are they really not being saved now? SSE support has recently been added to -current and -stable. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 10:47:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 7F91D37B405 for ; Tue, 21 Aug 2001 10:47:07 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7LHl5q39722; Tue, 21 Aug 2001 11:47:06 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7LHl1W66995; Tue, 21 Aug 2001 11:47:05 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108211747.f7LHl1W66995@harmony.village.org> To: Wes Peters Subject: Re: wireless nic recommendations Cc: Dan Cox , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 21 Aug 2001 10:16:37 MDT." <3B828965.C75C7639@softweyr.com> References: <3B828965.C75C7639@softweyr.com> <004301c127bd$c4dc5200$0100a8c0@network> Date: Tue, 21 Aug 2001 11:47:01 -0600 From: Warner Losh 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 <3B828965.C75C7639@softweyr.com> Wes Peters writes: : I've had no problems with this card, it is currently reaching about 6.5 : miles without an amplifier, using a 24 dB "fruit basket" antenna on the : roof of my house. What does the other end have? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 10:56:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 60F1A37B444 for ; Tue, 21 Aug 2001 10:56:19 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 303C281D0A; Tue, 21 Aug 2001 12:56:09 -0500 (CDT) Date: Tue, 21 Aug 2001 12:56:09 -0500 From: Alfred Perlstein To: Rex Luo Cc: hackers@FreeBSD.ORG Subject: Re: unpaired splbio() and splx() in vfs_unmountall() Message-ID: <20010821125609.F81307@elvis.mu.org> References: <200108210914.RAA02022@synology.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108210914.RAA02022@synology.com>; from rexluo@synology.com on Tue, Aug 21, 2001 at 05:14:51PM +0800 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 * Rex Luo [010821 04:14] wrote: > Dear, > > I modifid kernel to write to disk directly after unmount all mounted > filesystem in boot() kern/kern_shutdown.c. However, I found that my IO requests > wouldn't have callback from device interrupt routine. I traced the codes and use > gdb to find something out. The interesting is after execute > > vfs_unmountall() -> dounmount() -> ffs_unmount() -> ffs_flushfiles() -> > vflush()-> ??? the interrupt mask is set by splbio() without splx(), > therefore, all my following requests cannot return. > > Notice that, the situation only happens after heavy IO, for example: cp 30 files > at the same time. > > I use spl0() to solve the prolbem, but I think it's not the right way to do > that. Can anyone provide some clues or suggestions. That makes no sense. All you need to do is find the where the splbio() is that doesn't have a corresponding splx(). You can use the SPLASSERT functions to do that. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 11: 1:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 6E6AA37B40E for ; Tue, 21 Aug 2001 11:01:52 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7A43D81D15; Tue, 21 Aug 2001 13:01:52 -0500 (CDT) Date: Tue, 21 Aug 2001 13:01:52 -0500 From: Alfred Perlstein To: Giorgos Verigakis Cc: freebsd-hackers@freebsd.org Subject: Re: Zope's performance issues (cont.) Message-ID: <20010821130152.H81307@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from verigak@algol.vtrip-ltd.com on Tue, Aug 21, 2001 at 06:52:33PM +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 * Giorgos Verigakis [010821 10:55] wrote: > To check if it was indeed a thread problem, I repeated my tests > using Zope-2.4.0 and python 2.1.1 > First I did a default python compilation (using libc_r) and then > using pth (GNU portable threads) > > Using the program I sent on my previous email and a hit rate of 100 > I got > libc_r: 243 sec, 28 real hits/sec > pth: 15 sec, 36 real hits/sec > > So, I guess there is some problem on libc_r > > Giorgos > > PS: I did the same on OpenBSD and had similar results Do you think you could link it using profiling? 'cc -pg' Then run zope, then use gprof to see what's going on? -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 12:37:33 2001 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 BA2E537B405; Tue, 21 Aug 2001 12:37:26 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f7LJbQV04623; Tue, 21 Aug 2001 12:37:26 -0700 Date: Tue, 21 Aug 2001 12:37:26 -0700 From: Brooks Davis To: sos@freebsd.org Cc: hackers@freebsd.org Subject: tunable support for ata interrupt sharing Message-ID: <20010821123726.A15204@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Attached it a patch to make sharing of the main ata control interrupts dependent on a tunable, hw.ata.shared_irqs. This is required for my new HP Omnibook 500 to use the CMD 648 in the expansion base to work as it appears hardwired to interrupt 15 (which is fairly logical given that there is no where to attach devices to the secondary channel.) If this looks ok and you don't have time to deal with it, I'd be happy to commit it myself. -- 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 Index: sys/dev/ata/ata-pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/dev/ata/ata-pci.c,v retrieving revision 1.6 diff -u -r1.6 ata-pci.c --- sys/dev/ata/ata-pci.c 8 Jun 2001 09:51:33 -0000 1.6 +++ sys/dev/ata/ata-pci.c 21 Aug 2001 05:08:32 -0000 @@ -49,6 +49,15 @@ #include #include =20 +/* internal vars */ +static int shared_irqs =3D 0; +TUNABLE_INT("hw.ata.shared_irqs", &shared_irqs); + +/* systcl vars */ +SYSCTL_DECL(_hw_ata); +SYSCTL_INT(_hw_ata, OID_AUTO, shared_irqs, CTLFLAG_RD, &shared_irqs, 0, + "Share PCI IRQs?"); + /* misc defines */ #define IOMASK 0xfffffffc #define ATA_MASTERDEV(dev) ((pci_get_progif(dev) & 0x80) && \ @@ -515,7 +524,8 @@ =20 return BUS_ALLOC_RESOURCE(device_get_parent(dev), child, SYS_RES_IRQ, rid, - irq, irq, 1, flags & ~RF_SHAREABLE); + irq, irq, 1, flags & + (shared_irqs ? ~0 : ~RF_SHAREABLE)); #endif } else { Index: share/man/man4/ata.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/share/man/man4/ata.4,v retrieving revision 1.20 diff -u -r1.20 ata.4 --- share/man/man4/ata.4 14 Jul 2001 19:40:46 -0000 1.20 +++ share/man/man4/ata.4 21 Aug 2001 19:19:56 -0000 @@ -71,6 +71,9 @@ .It Va hw.ata.tags set to 1 to enable Tagged Queuing support (default is disabled) (only IBM DPTA and DTLA drives support that) +.It Va hw.ata.shared_irqs +set to 1 to allow sharing interrupts with the main controler +(default is disabled) .El .Sh DESCRIPTION This driver provides access to disk drives, ATAPI CD-ROM and DVD drives, --mYCpIKhGyMATD0i+ 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 iD8DBQE7grh0XY6L6fI4GtQRAlrqAKDaFEALwkJj3a5YIQxhkfME/QdSCgCfYuDG 1b2y4IcMRrxcyzUeMM8A7BQ= =dQu/ -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 12:41:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 58E0837B403; Tue, 21 Aug 2001 12:41:34 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f7LJfoP18640; Tue, 21 Aug 2001 21:41:50 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200108211941.f7LJfoP18640@freebsd.dk> Subject: Re: tunable support for ata interrupt sharing In-Reply-To: <20010821123726.A15204@Odin.AC.HMC.Edu> "from Brooks Davis at Aug 21, 2001 12:37:26 pm" To: Brooks Davis Date: Tue, 21 Aug 2001 21:41:50 +0200 (CEST) Cc: sos@freebsd.org, hackers@freebsd.org Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 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 seems Brooks Davis wrote: > Attached it a patch to make sharing of the main ata control interrupts > dependent on a tunable, hw.ata.shared_irqs. This is required for my new > HP Omnibook 500 to use the CMD 648 in the expansion base to work as it > appears hardwired to interrupt 15 (which is fairly logical given that > there is no where to attach devices to the secondary channel.) If this > looks ok and you don't have time to deal with it, I'd be happy to commit > it myself. I have just today committed always sharing all irq's to -current, the consensus is that if the BIOS allows sharing it should work. This makes sense, the MB maker is the only one that knows if this is working, if they blow it in thier BIOS, well.... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 12:42:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id C73EE37B405 for ; Tue, 21 Aug 2001 12:42:42 -0700 (PDT) (envelope-from oppermann@monzoon.net) Received: (qmail 50710 invoked from network); 21 Aug 2001 19:41:54 -0000 Received: from unknown (HELO monzoon.net) ([62.48.21.227]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 21 Aug 2001 19:41:54 -0000 Message-ID: <3B82B96E.F22EB480@monzoon.net> Date: Tue, 21 Aug 2001 21:41:34 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Cc: freebsd-small@freebsd.org Subject: How to make bootable disk boot images with vn device? 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, I've run into a (hopefully small) roadblock here. What I want to do is to make a comlete bootable 'disk' image for a IDE flash disk. This disk image should be simply dd-able to the target flash and include boot blocks and partition table etc. So far I did a flash image by putting a IDE flash onto the IDE bus a second disk, fdisk'd and label'd it, put the kernel and all the binaries onto it. Then "dd if=/dev/ad1 of=/images/flash-image.dd" to get a image I can dd back to the next flash. Now I'd like to make the generation of the master dd image a little bit easier and avoid the need of having a flash in the build machine. This is how I came via the PXE netboot stuff to the vn device and vnconfig. For some reason I'm missing how I can create a full disk image with this. Appearently the fdisk step is missing and I never get such a image dd' to a flash to boot. So here I'm lost. Any help appreciated. # dd if=/dev/zero of=mfsroot bs=1k count=25000 # vnconfig -e -s labels vn0 mfsroot # disklabel -r -w vn0 auto # newfs /dev/vn0c # mount and cp blabla TIA -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 12:43: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 2F56137B436 for ; Tue, 21 Aug 2001 12:42:52 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 83247 invoked by uid 3193); 21 Aug 2001 19:42:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Aug 2001 19:42:51 -0000 Date: Tue, 21 Aug 2001 15:42:51 -0400 (EDT) From: Mike Silbersack X-Sender: To: Giorgos Verigakis Cc: Subject: Re: Zope's performance issues 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 Tue, 21 Aug 2001, Giorgos Verigakis wrote: > On Tue, 21 Aug 2001, Mike Silbersack wrote: > > I suspect that the reload time spiking is due to our initial sequence > > number generation scheme, which is currently shared with OpenBSD. This > > will be changing RSN, which will likely change how your benchmarks look. > > (They should look better after the change.) > > I don't understand. How is it related with the initial sequence number? > > > > > > I'm curious about the reload time, though. Is it really in seconds? What > > is it measuring? > > Yes it's in seconds. What I wanted to measure was the time a page needs to > be loaded, because the results I was getting were unexpectable. The current scheme causes problems with TIME_WAIT recycling, which may cause long delays in establishing new connections if you're connection to the same host rapidly enough to cause TIME_WAIT recycling to be an issue. This is why there's a huge spike only when you get to 1000 hits/second. There could be other reasons, of course, but this will overshadow the others. I tested your test program with apache, and the change is noticeable. So, hold off on further testing until later this week. 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 Tue Aug 21 13:41:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 7820637B50F for ; Tue, 21 Aug 2001 13:40:56 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 96305 invoked by uid 3193); 21 Aug 2001 20:40:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Aug 2001 20:40:54 -0000 Date: Tue, 21 Aug 2001 16:40:54 -0400 (EDT) From: Mike Silbersack X-Sender: To: Giorgos Verigakis Cc: Subject: Re: Zope's performance issues 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 Tue, 21 Aug 2001, Mike Silbersack wrote: > On Tue, 21 Aug 2001, Giorgos Verigakis wrote: > > The current scheme causes problems with TIME_WAIT recycling, which may > cause long delays in establishing new connections if you're connection to > the same host rapidly enough to cause TIME_WAIT recycling to be an issue. > This is why there's a huge spike only when you get to 1000 hits/second. > > There could be other reasons, of course, but this will overshadow the > others. I tested your test program with apache, and the change is > noticeable. So, hold off on further testing until later this week. > > Mike "Silby" Silbersack There's a second problem with your program too: It causes TIME_WAITs to pile up on the client side, which is not a well-handled situation for us. Use apachebench for future testing, it will automatically generate the stats you are looking for. 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 Tue Aug 21 13:50:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from algol.vtrip-ltd.com (algol.vtrip-ltd.com [139.91.200.19]) by hub.freebsd.org (Postfix) with ESMTP id B6B5C37B407 for ; Tue, 21 Aug 2001 13:50:12 -0700 (PDT) (envelope-from verigak@vtrip-ltd.com) Received: from verigak (helo=localhost) by algol.vtrip-ltd.com with local-esmtp (Exim 3.12 #1 (Debian)) id 15ZIQY-0007Fe-00; Tue, 21 Aug 2001 23:47:10 +0300 Date: Tue, 21 Aug 2001 23:47:10 +0300 (EEST) From: Giorgos Verigakis To: Mike Silbersack Cc: Subject: Re: Zope's performance issues 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 Tue, 21 Aug 2001, Mike Silbersack wrote: > The current scheme causes problems with TIME_WAIT recycling, which may > cause long delays in establishing new connections if you're connection to > the same host rapidly enough to cause TIME_WAIT recycling to be an issue. > This is why there's a huge spike only when you get to 1000 hits/second. No, maybe I wasn't clear. I didn't get 1000 hits/sec, what I said was that I measured the time a page needs to be loaded after the program had made 1000 hits to Zope (so that it would be a bit a loaded). Also I don't know if this is caused by TIME_WAIT because when I do a netstat I don't see a lot of connections on TIME_WAIT Actually I think it has to do with the threads library (see my other mail on that) > > There could be other reasons, of course, but this will overshadow the > others. I tested your test program with apache, and the change is > noticeable. So, hold off on further testing until later this week. > > 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 Tue Aug 21 13:55:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from algol.vtrip-ltd.com (algol.vtrip-ltd.com [139.91.200.19]) by hub.freebsd.org (Postfix) with ESMTP id CC91B37B403 for ; Tue, 21 Aug 2001 13:55:12 -0700 (PDT) (envelope-from verigak@vtrip-ltd.com) Received: from verigak (helo=localhost) by algol.vtrip-ltd.com with local-esmtp (Exim 3.12 #1 (Debian)) id 15ZIVU-0007G4-00; Tue, 21 Aug 2001 23:52:16 +0300 Date: Tue, 21 Aug 2001 23:52:16 +0300 (EEST) From: Giorgos Verigakis To: Mike Silbersack Cc: Subject: Re: Zope's performance issues 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 Tue, 21 Aug 2001, Mike Silbersack wrote: > > On Tue, 21 Aug 2001, Mike Silbersack wrote: > > > On Tue, 21 Aug 2001, Giorgos Verigakis wrote: > > > > The current scheme causes problems with TIME_WAIT recycling, which may > > cause long delays in establishing new connections if you're connection to > > the same host rapidly enough to cause TIME_WAIT recycling to be an issue. > > This is why there's a huge spike only when you get to 1000 hits/second. > > > > There could be other reasons, of course, but this will overshadow the > > others. I tested your test program with apache, and the change is > > noticeable. So, hold off on further testing until later this week. > > > > Mike "Silby" Silbersack > > There's a second problem with your program too: It causes TIME_WAITs to > pile up on the client side, which is not a well-handled situation for us. > Use apachebench for future testing, it will automatically generate the > stats you are looking for. Yes tou are right on that, it was that on my system (the client) the connections were closing after a few seconds and I hadn't noticed it. > > Mike "Silby" Silbersack > > > 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 Tue Aug 21 14: 5:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0E43837B409; Tue, 21 Aug 2001 14:05:06 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA43849; Tue, 21 Aug 2001 14:16:57 -0700 (PDT) Date: Tue, 21 Aug 2001 14:16:56 -0700 (PDT) From: Julian Elischer To: Andre Oppermann Cc: freebsd-hackers@freebsd.org, freebsd-small@freebsd.org Subject: Re: How to make bootable disk boot images with vn device? In-Reply-To: <3B82B96E.F22EB480@monzoon.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 Theoretically teh fdisk step is not required becasue the disklable has, in it, a dummy fdisk. This is what is called "dangerously dedicated" mode. it usually works but MIGHT confuse BIOSes if there is something tricky about the system. On Tue, 21 Aug 2001, Andre Oppermann wrote: > Hello, > > I've run into a (hopefully small) roadblock here. > > What I want to do is to make a comlete bootable 'disk' image for a > IDE flash disk. This disk image should be simply dd-able to the target > flash and include boot blocks and partition table etc. > > So far I did a flash image by putting a IDE flash onto the IDE bus a > second disk, fdisk'd and label'd it, put the kernel and all the > binaries onto it. Then "dd if=/dev/ad1 of=/images/flash-image.dd" to > get a image I can dd back to the next flash. > > Now I'd like to make the generation of the master dd image a little > bit easier and avoid the need of having a flash in the build machine. > > This is how I came via the PXE netboot stuff to the vn device and > vnconfig. > > For some reason I'm missing how I can create a full disk image with > this. Appearently the fdisk step is missing and I never get such a > image dd' to a flash to boot. So here I'm lost. Any help appreciated. > > # dd if=/dev/zero of=mfsroot bs=1k count=25000 > # vnconfig -e -s labels vn0 mfsroot > # disklabel -r -w vn0 auto > # newfs /dev/vn0c > # mount and cp blabla Is this what you WANT or what you are doing now? > > TIA > -- > Andre > > 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 Tue Aug 21 14: 5:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id ADB9237B430; Tue, 21 Aug 2001 14:05:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA43807; Tue, 21 Aug 2001 14:04:50 -0700 (PDT) Date: Tue, 21 Aug 2001 14:04:50 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Peter Wemm , Leo Bicknell , Matt Dillon , hackers@FreeBSD.ORG, murray@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Recommendation for minor KVM adjustments for the release In-Reply-To: <3B824716.2398B45A@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 On Tue, 21 Aug 2001, Terry Lambert wrote: > Peter Wemm wrote: > > No. I have a machine with 6GB in it waiting for finishing the PAE > > tweaks. > > Are you actually going ahead with the PAE support? > > Will this be a compile-time option, so that it can be > turned off? > > I considered doing the same, about 4 months ago but it's not > like I could use the additional memory for mbufs, sockets, or > other useful kernel structures, so I bailed on completing it. If you have the correct hardware, it can be used for mbufs, bufs, or normal user memeory.. > 8-(. > > -- 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 Tue Aug 21 16:47:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by hub.freebsd.org (Postfix) with SMTP id E513D37B418 for ; Tue, 21 Aug 2001 16:46:58 -0700 (PDT) (envelope-from kc5vdj@yahoo.com) Received: from mkc-65-28-47-209.kc.rr.com (HELO yahoo.com) (65.28.47.209) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Aug 2001 23:46:58 -0000 X-Apparently-From: Message-ID: <3B82F2F2.20901@yahoo.com> Date: Tue, 21 Aug 2001 18:46:58 -0500 From: Jim Bryant Reply-To: kc5vdj@yahoo.com User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Any ATAPI gurus out there? Content-Type: text/plain; charset=us-ascii; format=flowed 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 Okay, here's the deal. My friend, whom I am trying to teach unix [4.3-stable] was having some problems on his secondary ATAPI bus. A Creative CD-ROM was the master, a HP burner was the slave. I'm a SCSI guy meself, and I think the following may be the problem, but as such, I don't know for sure... The CD-ROM was having data dropouts, and was due to old age, no doubt. Under Winblowz, the HP burner would only get 4x when it was able to burn. it's a 12x/8x/32x drive. Under BSD, the CD-ROM would be usable, but would be prone to dropouts. Under BSD, the HP burner came up with sense errors on boot, prior to a proper probe reply. It would hang for the duration of several timeouts at the point before it got the probe. Under BSD, the HP burner would cause a terminal wait state upon any access [such as a mount request, or a burncd command]. Red-button time... This last Friday, he bought a new CD-ROM, and a new burner, as we both thought both drives had issues. He gave me the burner [after a promise to pay him $50 for the under-a-year-old burner, assuming I could "fix" it]... He put his new drives in his box. Everything works now, under Winblowz AND BSD. I put the the HP burner in MY box, and voila! Nothing is wrong with it... Questions: 1). Can a flaky ATAPI "Master" cause a good ATAPI "Slave" to APPEAR [however incorrectly] that the "Slave" has a problem? 2). If #1 is true, then, why? One added benefit, I've been pushing him to go SCSI [with the good eBay prices on reliable used and new drives, as well as the independance of the drives, the speed, etc... This has gotten him one step closer to committing to SCSI, so not all is lost in this story.. He got two new drives, I got a helluva deal on a good burner, and he may convert to SCSI... I am relatively ignorant on ATAPI matters, and under SCSI the devices are independant, but we do have this question concerning the "Master/Slave" thing... jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 17: 7:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 7CE9A37B421 for ; Tue, 21 Aug 2001 17:07:12 -0700 (PDT) (envelope-from jdp@wall.polstra.com) 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 f7M075X22329; Tue, 21 Aug 2001 17:07:05 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.5/8.11.0) id f7M074t05748; Tue, 21 Aug 2001 17:07:04 -0700 (PDT) (envelope-from jdp) Date: Tue, 21 Aug 2001 17:07:04 -0700 (PDT) Message-Id: <200108220007.f7M074t05748@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: dan@langille.org Subject: Re: ld -X <== important or not? In-Reply-To: <3B7FE5C2.18273.16C3288@localhost> References: <3B7FE5C2.18273.16C3288@localhost> 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 <3B7FE5C2.18273.16C3288@localhost>, Dan Langille wrote: > How important is the -X option on ld? > > -X Delete all temporary local symbols. For most tar- > gets, this is all local symbols whose names begin > with `L'. > > I ask because I'm porting something to Solaris and it seems rather > odd that the solaris ld doesn't have this option. It's not important. It just makes the output file smaller. I wouldn't be surprised if the Solaris linker did this by default. John -- John Polstra jdp@polstra.com 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 Tue Aug 21 17:34:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from voyager.galileo.edu (samsara.galileo.edu [168.234.203.5]) by hub.freebsd.org (Postfix) with SMTP id 9D8FA37B410 for ; Tue, 21 Aug 2001 17:34:27 -0700 (PDT) (envelope-from obonilla@galileo.edu) Received: (qmail 5940 invoked by uid 1001); 22 Aug 2001 00:34:32 -0000 Date: Tue, 21 Aug 2001 18:34:32 -0600 From: Oscar Bonilla To: Darryl Okahata Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: secure Filesystem Message-ID: <20010821183432.A5883@galileo.edu> References: <200108161948.MAA03510@mina.soco.agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108161948.MAA03510@mina.soco.agilent.com>; from darrylo@soco.agilent.com on Thu, Aug 16, 2001 at 12:48:59PM -0700 X-Mailer: Mutt 1.2i (2000-05-09) 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, Aug 16, 2001 at 12:48:59PM -0700, Darryl Okahata wrote: > A bigger problem is that doing anything with a file uses up 1-2KB > PER FILE. If you want to see cfsd grow *really big*, do a "find ." of > any large cfs-controlled hierarchy with lots of files. I'd really like > to put my MH mail messages under cfs, but I've got too many files (I > can't afford having a 200+MB cfsd). I don't seem to have that problem... voyager ~ > du -sk crypt 1342056 crypt voyager ~ > find /crypt/obonilla >& /dev/null voyager ~ > du -sk crypt 1342056 crypt am i missing something? should i just be happy ;) regards, -oscar -- pgp fingerprint: BC64 2E7A CAEF 39E1 9544 80CA F7D5 784D FB46 16C1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 18: 3:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by hub.freebsd.org (Postfix) with ESMTP id 6E8D537B413 for ; Tue, 21 Aug 2001 18:03:11 -0700 (PDT) (envelope-from darrylo@soco.agilent.com) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id EA5029C1; Tue, 21 Aug 2001 19:03:10 -0600 (MDT) Received: from mina.soco.agilent.com (mina.soco.agilent.com [141.121.54.157]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 5B619CB0; Tue, 21 Aug 2001 19:03:10 -0600 (MDT) Received: from mina.soco.agilent.com (darrylo@localhost [127.0.0.1]) by mina.soco.agilent.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id SAA05763; Tue, 21 Aug 2001 18:03:09 -0700 (PDT) Message-Id: <200108220103.SAA05763@mina.soco.agilent.com> To: Oscar Bonilla Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: secure Filesystem Reply-To: Darryl Okahata In-Reply-To: Your message of "Tue, 21 Aug 2001 18:34:32 MDT." <20010821183432.A5883@galileo.edu> Mime-Version: 1.0 (generated by tm-edit 1.6) Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Aug 2001 18:03:08 -0700 From: Darryl Okahata 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 Oscar Bonilla wrote: > > A bigger problem is that doing anything with a file uses up 1-2KB > > PER FILE. If you want to see cfsd grow *really big*, do a "find ." of > > any large cfs-controlled hierarchy with lots of files. I'd really like > > to put my MH mail messages under cfs, but I've got too many files (I > > can't afford having a 200+MB cfsd). > > I don't seem to have that problem... > > voyager ~ > du -sk crypt > 1342056 crypt > voyager ~ > find /crypt/obonilla >& /dev/null > voyager ~ > du -sk crypt > 1342056 crypt No. You need lots of files, not lots of disk space used. [ You might have lots of files, but I can't tell from the above. ] Assuming that you have lots of files (> 10000, if possible) below /crypt/obonilla, you need to look at the size of the cfsd daemon. The disk space taken will not change -- it's the memory consumption of the cfsd daemon. If you have only a few files (oh, say, < 1000), you're probably fine. If you have lots of RAM (oh, 256MB or more), you may not notice any problems. [ For an easy way of seeing cfsd grow, run top(1) *WHILE* the find(1) is running. Look at the "Size" and "Res" fields. ] Also, if you have lots of files, the find(1) of the cfs-controlled hierarchy should run significantly slower than if find(1) was running on a plain hierarchy. The reason is that cfsd uses a 1024-entry hash table at the top level; everything's a linked list below that (I think). Due to the size of this table, cfsd will thrash the disk if the system goes into swap. I may play with bumping the table size up to 128K or so (I'm not sure if the hash function can handle it, though). Increasing the table size might help lessen the thrashing. -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 18: 7:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from comnet.ca (comnet.ca [216.191.240.2]) by hub.freebsd.org (Postfix) with ESMTP id 106A537B408 for ; Tue, 21 Aug 2001 18:07:16 -0700 (PDT) (envelope-from webdesigns@comnet.ca) Received: from critter (shellsandhosting.com [64.39.176.9]) by comnet.ca (8.11.3/8.11.3) with SMTP id f7M17Ef28634 for ; Tue, 21 Aug 2001 21:07:15 -0400 (EDT) Message-ID: <001b01c12aa6$b292afe0$0200000a@critter> From: "webdesigns COMNET" To: Subject: vhost problems Date: Tue, 21 Aug 2001 21:06:38 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C12A85.2AE6CBB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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_0018_01C12A85.2AE6CBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, For the last week I have been trying everything I know to try an work = out my problem. Since it seems I have exausted all my resources, I = figured I'd try here. I'm trying to export vhosts on my system and it isnt working. I'm using FreeBSD 4.4-RC, along with ipnat/ipf and my connection is = pppoe. I have 1 assigned ip I connect with(static), the one tun0 obtains. I also have a block of static external addressed assigned on my external = interface rl0, also obtained from my isp. My connection ip isn't from the same ip block as my /29 obtained from my = ISP. It seems all my incoming connections to each different ip on the block = worka fine. I am fully able to ipnat the ip to another internal box via = sis0 the internal interface. The problem is all my outbound connections are all seen as from tun0 = interface ip, even when I export an ip or hostname locally. How is it possible to be able to export hosts, and have one of my ip = block addresses seen on the internet, as opposed to having all outbound = traffic seen from the 1 tun0 connection ip? Jason admin@shellsandhosting.com ------=_NextPart_000_0018_01C12A85.2AE6CBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone,
 
For the last week I have been trying = everything I=20 know to try an work out my problem. Since it seems I have exausted all = my=20 resources, I figured I'd try here.
I'm trying to export vhosts on my = system and it=20 isnt working.
I'm using FreeBSD 4.4-RC, along with = ipnat/ipf and=20 my connection is pppoe.
I have 1 assigned ip I connect = with(static), the=20 one tun0 obtains.
I also have a block of static external = addressed=20 assigned on my external interface rl0, also obtained from my = isp.
My connection ip isn't from the same ip = block as my=20 /29 obtained from my ISP.
It seems all my incoming connections to = each=20 different ip on the block worka fine. I am fully able to ipnat the ip to = another=20 internal box via sis0 the internal interface.
The problem is all my outbound = connections are all=20 seen as from tun0 interface ip, even when I export an ip or hostname=20 locally.
How is it possible to be able to export = hosts, and=20 have one of my ip block addresses seen on the internet, as opposed to = having all=20 outbound traffic seen from the 1 tun0 connection ip?
 
Jason
admin@shellsandhosting.com=
------=_NextPart_000_0018_01C12A85.2AE6CBB0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 19:52: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from synology.com (dns1.synology.com [202.173.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 3A73537B40D for ; Tue, 21 Aug 2001 19:51:57 -0700 (PDT) (envelope-from rexluo@synology.com) Received: from synology.com (IDENT:nobody@localhost [127.0.0.1]) by synology.com (8.9.3/8.9.3) with SMTP id KAA07814; Wed, 22 Aug 2001 10:52:40 +0800 Date: Wed, 22 Aug 2001 10:52:40 +0800 Message-Id: <200108220252.KAA07814@synology.com> To: Alfred Perlstein , Rex Luo Subject: Re: unpaired splbio() and splx() in vfs_unmountall() From: Rex Luo X-Mailer: TWIG Cc: hackers@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 Dear Alfred, I have tried to add several asserts to verify its interrupt mask, however, the abnormal behaviour disappered if I did that. That's really rediculous and I don't know why? I would continue to find out what's the reason, and feedback if something new. Anyway, I really appreciate your help and kindness. Further question, what kind of books, or news, information I can get to study about pc's interrupt handling and architecture. Thanks, -- Rex Luo Alfred Perlstein said: > * Rex Luo [010821 04:14] wrote: > > Dear, > > > > I modifid kernel to write to disk directly after unmount all mounted > > filesystem in boot() kern/kern_shutdown.c. However, I found that my IO requests > > wouldn't have callback from device interrupt routine. I traced the codes and use > > gdb to find something out. The interesting is after execute > > > > vfs_unmountall() -> dounmount() -> ffs_unmount() -> ffs_flushfiles() -> > > vflush()-> ??? the interrupt mask is set by splbio() without splx(), > > therefore, all my following requests cannot return. > > > > Notice that, the situation only happens after heavy IO, for example: cp 30 files > > at the same time. > > > > I use spl0() to solve the prolbem, but I think it's not the right way to do > > that. Can anyone provide some clues or suggestions. > > That makes no sense. All you need to do is find the where the splbio() > is that doesn't have a corresponding splx(). You can use the SPLASSERT > functions to do that. > > -- > -Alfred Perlstein [alfred@freebsd.org] > Ok, who wrote this damn function called '??'? > And why do my programs keep crashing in it? > -- Rex Luo Tel : 886-2-25521814 Ext. 824 Fax : 886-2-25521824 e-mail : rexluo@synology.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 22:42:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 058C337B412; Tue, 21 Aug 2001 22:42:02 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id f7M5flc23520; Wed, 22 Aug 2001 07:41:47 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id f7M5flm01187; Wed, 22 Aug 2001 07:41:47 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.11.3/8.11.3) id f7M5fkK57899; Date: Wed, 22 Aug 2001 07:41:46 +0200 From: Andre Albsmeier To: Warner Losh Cc: David Malone , walter@pelissero.org, John Baldwin , net@FreeBSD.ORG, hackers@FreeBSD.ORG, Andre Albsmeier Subject: Re: 4.4-RC NFS panic Message-ID: <20010822074146.A34016@curry.mchp.siemens.de> References: <200108210935.aa87782@salmon.maths.tcd.ie> <200108211745.f7LHjCW66969@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108211745.f7LHjCW66969@harmony.village.org>; from imp@harmony.village.org on Tue, Aug 21, 2001 at 11:45:12AM -0600 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike 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, 21-Aug-2001 at 11:45:12 -0600, Warner Losh wrote: > In message <200108210935.aa87782@salmon.maths.tcd.ie> David Malone writes: > : Andre Albsmeier, who's seeing various network problems, is using > : the xe driver (also PCMCIA I think), but the problems go away if > : he uses an Etherexpress card on the PCI bus of the same machine. > : > : It seems unlikely to be PCMCIA related ('cos it has nothing to do > : with the networking itself) it may just be triggered in machines > : with slower networking. > > After talking with Ian Dowse, I think that we've hammered out what may > cause this. Basically, the problem is > > code in net doing splnet() > > -> pcic_pci_intr -> netcard_intr -> network code. > > And we've interrupted the critical section, broken all kinds of > invariants. > > Warner > > P.S. I think that with Ian's other interrupt changes, we can do the > following w/o problems. This should fix the network problems, I > think. Runs perfectly for about 10 minutes now under full load. It didn't survive 10 seconds before :-) I still have the hangs on a warm reboot but this is a different story... Thanks a lot for the quick help! -Andre > > Index: pcic_pci.c > =================================================================== > RCS file: /cache/ncvs/src/sys/pccard/pcic_pci.c,v > retrieving revision 1.54.2.7 > diff -u -r1.54.2.7 pcic_pci.c > --- pcic_pci.c 2001/08/21 09:06:25 1.54.2.7 > +++ pcic_pci.c 2001/08/21 17:18:06 > @@ -515,15 +515,6 @@ > * in the CD change. > */ > sp->getb(sp, PCIC_STAT_CHG); > - > - /* > - * If we have a card in the slot with an interrupt handler, then > - * call it. Note: This means that each card can have at most one > - * interrupt handler for it. Since multifunction cards aren't > - * supported, this shouldn't cause a problem in practice. > - */ > - if (sc->cd_present && sp->intr != NULL) > - sp->intr(sp->argp); > } > > /* > @@ -784,36 +775,6 @@ > return (0); > } > > -static int > -pcic_pci_setup_intr(device_t dev, device_t child, struct resource *irq, > - int flags, driver_intr_t *intr, void *arg, void **cookiep) > -{ > - struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev); > - struct pcic_slot *sp = &sc->slots[0]; > - > - if (sp->intr) { > - device_printf(dev, > -"Interrupt already established, possible multiple attach bug.\n"); > - return (EINVAL); > - } > - sp->intr = intr; > - sp->argp = arg; > - *cookiep = sc; > - return (0); > -} > - > -static int > -pcic_pci_teardown_intr(device_t dev, device_t child, struct resource *irq, > - void *cookie) > -{ > - struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev); > - struct pcic_slot *sp = &sc->slots[0]; > - > - sp->intr = NULL; > - sp->argp = NULL; > - return (0); > -} > - > static device_method_t pcic_pci_methods[] = { > /* Device interface */ > DEVMETHOD(device_probe, pcic_pci_probe), > @@ -829,8 +790,8 @@ > DEVMETHOD(bus_release_resource, bus_generic_release_resource), > DEVMETHOD(bus_activate_resource, pcic_activate_resource), > DEVMETHOD(bus_deactivate_resource, pcic_deactivate_resource), > - DEVMETHOD(bus_setup_intr, pcic_pci_setup_intr), > - DEVMETHOD(bus_teardown_intr, pcic_pci_teardown_intr), > + DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), > + DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr), > > /* Card interface */ > DEVMETHOD(card_set_res_flags, pcic_set_res_flags), -- BSD, from the people who brought you TCP/IP. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 22:45: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 30F6037B436; Tue, 21 Aug 2001 22:44:44 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7M5igq41737; Tue, 21 Aug 2001 23:44:42 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7M5ifW72264; Tue, 21 Aug 2001 23:44:41 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108220544.f7M5ifW72264@harmony.village.org> To: Andre Albsmeier Subject: Re: 4.4-RC NFS panic Cc: David Malone , walter@pelissero.org, John Baldwin , net@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 22 Aug 2001 07:41:46 +0200." <20010822074146.A34016@curry.mchp.siemens.de> References: <20010822074146.A34016@curry.mchp.siemens.de> <200108210935.aa87782@salmon.maths.tcd.ie> <200108211745.f7LHjCW66969@harmony.village.org> Date: Tue, 21 Aug 2001 23:44:40 -0600 From: Warner Losh 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 <20010822074146.A34016@curry.mchp.siemens.de> Andre Albsmeier writes: : I still have the hangs on a warm reboot but this is a different : story... Eh? what kind of hangs and when? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 21 23: 1: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 2D4BA37B408; Tue, 21 Aug 2001 22:59:56 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f7M5xhb09664; Wed, 22 Aug 2001 07:59:43 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id f7M5xhN17718; Wed, 22 Aug 2001 07:59:43 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.11.3/8.11.3) id f7M5xhK57987; Date: Wed, 22 Aug 2001 07:59:42 +0200 From: Andre Albsmeier To: Warner Losh Cc: Andre Albsmeier , David Malone , walter@pelissero.org, John Baldwin , net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: 4.4-RC NFS panic Message-ID: <20010822075942.A34091@curry.mchp.siemens.de> References: <20010822074146.A34016@curry.mchp.siemens.de> <200108210935.aa87782@salmon.maths.tcd.ie> <200108211745.f7LHjCW66969@harmony.village.org> <20010822074146.A34016@curry.mchp.siemens.de> <200108220544.f7M5ifW72264@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108220544.f7M5ifW72264@harmony.village.org>; from imp@harmony.village.org on Tue, Aug 21, 2001 at 11:44:40PM -0600 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike 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, 21-Aug-2001 at 23:44:40 -0600, Warner Losh wrote: > In message <20010822074146.A34016@curry.mchp.siemens.de> Andre Albsmeier writes: > : I still have the hangs on a warm reboot but this is a different > : story... > > Eh? what kind of hangs and when? Attached below is the dmesg... It hangs only when warm booting; after a power toggle everything is OK... Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-RC #23: Wed Aug 22 07:21:34 CEST 2001 root@bali.ofw.tld:/src/obj-4/src/src-4/sys/schlappy Calibrating clock(s) ... TSC clock: 366660160 Hz, i8254 clock: 1193146 Hz Timecounter "i8254" frequency 1193146 Hz CPU: Pentium II/Pentium II Xeon/Celeron (366.66-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x66a Stepping = 10 Features=0x183f9ff real memory = 134152192 (131008K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00325000 - 0x07febfff, 130838528 bytes (31943 pages) avail memory = 127590400 (124600K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6230 bios32: Entry = 0xfd790 (c00fd790) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x225 pnpbios: Found PnP BIOS data at 0xc00f6260 pnpbios: Entry = f0000:a34e Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ACPI: 000f61f0 Preloaded elf kernel "kernel" at 0xc02ff000. Pentium Pro MTRR support enabled pci_open(1): mode 1 addr port (0x0cf8) is 0x8000384c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) Using $PIR table, 7 entries at 0xc00fdf50 apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard found-> vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[10]: type 1, range 32, base f8000000, size 26 found-> vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1 secondarybus=1 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[20]: type 1, range 32, base 0000fcd0, size 4 found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=9 map[20]: type 1, range 32, base 0000fce0, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[90]: type 1, range 32, base 00002180, size 4 found-> vendor=0x104c, dev=0xac1c, revid=0x01 class=06-07-00, hdrtype=0x02, mfdev=1 subordinatebus=0 secondarybus=0 intpin=a, irq=10 found-> vendor=0x104c, dev=0xac1c, revid=0x01 class=06-07-00, hdrtype=0x02, mfdev=1 subordinatebus=0 secondarybus=0 intpin=b, irq=11 pci0: on pcib0 pcib1: at device 1.0 on pci0 found-> vendor=0x10c8, dev=0x0005, revid=0x12 class=03-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base f6000000, size 24 map[14]: type 1, range 32, base fe400000, size 22 map[18]: type 1, range 32, base feb00000, size 20 found-> vendor=0x10c8, dev=0x8005, revid=0x12 class=04-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 intpin=b, irq=11 map[10]: type 1, range 32, base f7800000, size 22 map[14]: type 1, range 32, base fea00000, size 20 pci1: on pcib1 pci1: (vendor=0x10c8, dev=0x0005) at 0.0 irq 10 chip1: mem 0xfea00000-0xfeafffff,0xf7800000-0xf7bfffff irq 11 at device 0.1 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcd0-0xfcdf at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xfcd0 ata0: mask=03 status0=50 status1=50 ata0: mask=03 ostat0=50 ostat2=50 ata0-slave: ATAPI probe a=14 b=eb ata0-master: ATAPI probe a=00 b=00 ata0: mask=03 status0=50 status1=00 ata0-master: ATA probe a=01 b=a5 ata0: devices=09 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xfcd8 ata1: mask=00 status0=ff status1=ff ata1: probe allocation failed pci0: (vendor=0x8086, dev=0x7112) at 7.2 irq 9 chip2: port 0x2180-0x218f at device 7.3 on pci0 pcic0: irq 10 at device 10.0 on pci0 pcic0: PCI Memory allocated: 0x44000000 pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][CSC serial isa irq] pccard0: on pcic0 pcic1: irq 11 at device 10.1 on pci0 pcic1: PCI Memory allocated: 0x44001000 pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][CSC serial isa irq] pccard1: on pcic1 ata-: ata0 exists, using next available unit number ata-: ata1 exists, using next available unit number pcic-: pcic0 exists, using next available unit number Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: newlogo




Personalise You Nokia with these great Logos!!!

Picture of Logo

Picture of BITCH
Picture of HOPE
Picture of Bomb
Picture of Dragon
Picture of BEER
Bitch
21692
Hope
21716
Sex Bomb
21740
Dragon 1
20110
Love Beer
20203
Picture of Fcuk
Picture of eyes
Picture of Trust
Picture ot rizla
Picture of Simpsons
fcuk
21951
Loving Eyes 20142
Trust No One 20409
Rizla
21256 
The Simpsons 20399



Call Now ON  "0906 400 2144"

Quote the 5 digit number and your logo / Ringtone will be sent immediately!!
 For many more please visit www.mobiledirect.uk.com




Get Your Mobile Rocking with these great Ringtones!!!

Picture of ringtones

Description
Code
Listen
Baha Men - Who let the dogs out
10138
Bob the Builder - Can We Fix It?
11107
Shaggy Feat Rikrok - It Wasn't Me
11762
The Simpsons
10009
James Bond Theme
10000
Star Wars Imperial March
10085


Please note: the call costs £1.50 per minute and the average call length is 2 minutes. Please ask bill payer for permission. Calls from mobiles cost more depending on service. The following phones receive both logos and tones - Nokia 3210, 3310,6090, 6110, 6130, 6150, 6210, 6250, 7110, 8110i, 8210, 8810, 8850, 9000i and 9110. Nokia models: 402 and 51XX receive logos only. Motorola T250, T2288, V50, V100, V2288, V8088 receive ring tones only. Please make sure that your mobile is listed here before ordering. Mobile Direct reserves the right not to refund your money if your phone is not listed here. If you experience any problem, call Customer Service on 0800 015 1175. Orders normally sent immediately, depending on network.

For hundreds more ringtones and logos just click on to www.mobiledirect.uk.com - pass this on to a friend or stick it on the notice board

Important Notice: If you do not wish to receive any more emails, please mail us on majordomo@mobiledirect.uk.com and click "send." and your address will removed


--------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhiAFAAPcAAP////39/Z+fn/n5+ZycnO7u7tXV1b29verq6vv7+/f399vb27GxsX9/ f2NjY7a2tnx8fPT09M/Pz2RkZOHh4fDw8IWFhY6OjpmZmZubm/Ly8tjY2KysrIuLi6Kiot3d 3cbGxtfX16SkpLOzs9HR0ZSUlMjIyLm5uaqqqu3t7dPT0+Pj4+fn56amps3NzYCAgIeHh6Cg oIKCgsPDw+Xl5cTExJKSkq6urqioqImJid7e3sDAwFVVVZeXl3FxcWdnZ/74+bq6umlpacvL yywsLHZ2duUsTB4eHkhISPEsT09PT2FhYXR0dFZWVj09PVBQUCMjI1paWisrKzQ0NM3NtRwc HCQkJAcHBzs7O0VFRScnJzExMQgICO8AKhYWFg4ODgAAAA0NDRAQEBISEgUFBd4AJwICAuU5 V3l5eY2NjdPTvunp6ZCQkLW1tfz8+m5ububm2uzs40dHR2tra3Nzc9bWw+wsTr6+vhoaGlNT U3p6euMsTPb28RkZGS4uLjIyMu4CLNKvtQsLCykpKUBAQENDQ2xsbO4sTv77/BUVFSAgIDc3 Nzg4OEtLS0xMTFlZWVxcXOMkReMlRucsTegsTfEpTPErTvorUO85Wu9QbOpbdNCts9CvteTG zOvDyv75+v7+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAiAFAAAAI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatwI0Q2cOlRCihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz0qwDx01D Pmp0Ch1KtKjRo0iTKl16Uw2fhW6CqonDsarVq1izat3KtavXhHGk+kwIh4qasV/Tql3Ltq3b t1ijUoGjMChVuHjz6t3Lt2/GOFTqKAzpt7Dhw4gTfyWckLHix5AjS54MwPFBy5Qza97MWSvm gp87ix5NuvRlKoNRm17NunXm0ANhu55Nu3Zb2ZVV297Nu7dn3ad9Cx9OnCJu3MWTKxd+HPjy 59B5N48IqLr164AIXh+I3eB27diz/nMP370gefPfwVcHQD79eOsQyzd0j/B8/fD35aOHX3VN Dx9LOCDggA4sQYcHKRgUQQxFEEiggTEkKNAQAi6RhkMJQBDgHAjEEKADKkDkAgxLfOjggzCA 5pyK1LXHH3sv4qeeeAK5+J6NN9oHI33bubhejvTlF6SQCvlII5Av1ujjjPpZFEEPeIAh5ZRU TkmECKAIBAoOWlTppZR+CCCQCFM64RAoVUy5gANTjtAQKCM0QsaXdPrBYmMrLmTkj+npuCON Riq5pKCD+tnjoIQ2edChP+qZ5H6I/qnjnoC2p9EPdGZKgEAwZEqnDACgMKUcZx6hpiFtNtSA p3ROcSdC/sh5tyehSM6YqH2z3oqrjLQGquuji/IHbLCNyuqrpJPmGmlFOiQypRhHHCHIlGNE K8aUVawBChRTXhHtt+BOK6UgLIwwKoY5+OBDEQVgKqWbC40w55RhgGvvt1U88Wpw8T36XZ/J 8snjkbRCWmx3lvY67I3gMfRvsQkNiSyTiaJ3K8XuQUxRGlMWskIEEaAxZQ8gbzDIlBlIgO0M ILfscgh9tPnAlEhQtESqCzVBZRUhKODzz0ADva9BsUJq9J9IVrqeouwZS7CkBiPbKKNP29ri 0hoTSSzECA8pXpNdZ40RBCMP1KmUmwqks5Q5mDDlBAshMWUbM0uZBSh45423/gIBEBSABDWA YAIoN7/L0NpSLgGA3ozrTXSesUEesb9Txwjfw1iLvbXTm1OtMI5S9yvx5qQbPXrBpvOa0apS XigQ62CkDQDiHbjw9kJyTPlA3WAIQsTvwP/uhxMwIKClH2aQIcgHc+CsEA9UjuFH8NT/LoUU MwytvaOIApz590gfzbD4tlKdnfmqJ+xwkFWjTj7D7F8+LOZMTwT7BQPBLjv0UtY+pQO40x3v WAWGPqQIFCcDAxmY57yE8I+AVWrD9iJ3NT+FL3yeix/XgOU1+QkMfMf61Xz00z73WS11GvMc 50SIkfvlb0r7m5L/pARAheROSruDIJXYAAApSIkL/gw03EIeqEMhUhBPFVSU975mKQ0SzImd E1YTl6WrIk2xhBd83+eepsL3WdB+U8Lf62A4kAfOEAxwU4jccMi7KkxgAg6awA/+MCUtVMAP PwwiGO7AECJq4QdwPJGDQkSQ6YjufAOrnCLDtsFGcnF+HlQaIytoxQ+eTmId/N4TI1k6LUrE hWNEWxllWIMpKU6Nc+OdIxISAUWMiwR0BAMQmyclPi4kD1T6gXEklxtKZvGCGZMRCSmXwkSC r1ang9EJV1ixSrYPbPQ7kvmipszxWQSUANDfKNm2gSkpIgYhCIEKxknODYzAWVIKAu+cYIB2 urOdGyAAOsOwgS1I6QoU/qDDlJRgAnGS858hAMAjdiaCDbzzoO0MwQYmKJCinTCYi2SSJUFn wl+VB6LoG6b6mPnLre3qWJSy6BJVRxFsalMgD0yRFajEhSu49KVX4AKVvrACc0nJDDCFqUzL pAA8guEKHwjBThXY0py61AsJGIG4plRUo8LUCgzt5SFzZE1jLvKLmSwUMSNpqI06jaIeFWau RCpJ0IGVImSTkhgBkNbYDQRxDQBADIoopRsA4AZ0FcMMQOFTMgQUVQQURAUAQCa6ggEPUXWo NaEGzK0ezKsVJetiJxbCsxoMshKVTwgtelmNkpQiepiS6wAQWlEKRAlT0sOYprBUOnFhCj0Q /kgLdBgGJ/BxW1MiAQAiAAFFmMFTZJAQBxrRh3kR0AuJ5WUnMWi5Yjq2hJckqRMRedb6fVWS kwPrF4GUXUwmEyIhwIAAMhBQgYRXAARYqEB2kAEBYKC8i9vADQgggPraF703WECWBEIB+taX AAAOMAEykIEbfKBvAEgABzAA4AIMRAMziEEGBCxgDwyAICm4w4ApzGEMxCC50QlxaUABhBIT hMQmPnGJEdEQRHyixPudjCFFTOPJZKISSUiCHYywByPYIcc6nkSPDwFkO0hiEkaYBJGBzGQm U4LHPs6xJS7hCVBEoAAJGAjeFjeAFERAy6BIQQo0MJAIrADBGqgA/ijSvN8AtLlveCuAl3db ACvXGcQ1zrNVLmwVSZThz4AOtKAHTehCG7oLnDAQAZYAgwQkoAkfJkAjBJCGJei2CHmIAQH4 qIAlMCEGStjUHXKABQgwYL8wmMKFIEAHAKRBDgC2KwhKgAUm4IDPR4SVcgeCaz37Wi2TMLSw h01sQAMiEIrgoblqAAAvpOgNixAIHh4BgEIQIgAITkMVEvSCNwhEZQwgCCS+YIVHEwIAE1DE ABAMgBSAIbaPS82v512YYBf73vj+87H9EFsNkCEDADhCivSABz0wwQkSVEIVGkCALC2i1QUJ ARkkOJA8MEEIS4hCIwDwhi80oHgCSQEZ/mRXSF4qlt4o54q9881yYe8b4CsAg12rYAEA0AEK nfowAOQghy3PLg8CWUENskQCMrhpv0qAgMQVsXEhKAIUWRZIAcgAbzynXMTs5kskWs71Qndh E39AAgSeEAUEJIDmNmfEXaGwqUZAQQYv8AAAQrAIC02hAUSfuM3t+gQfAMAHYAD6GxLxAhj0 IMtTr3rJ5X31xrdFE2eIvOQnT/nKW/7ymMdEJ1xwAxGYQEs7+AAANgACgdSAjyQYQQxiYMsU xCANLnjwCRK0gwUAwAUBBcUDYr8BBrRABCPIEihOsAJ+6drxyE8+V2as/OY7HyPMf770p++Q 6FP/+thfPBI5/rKBAzjYIC44AQDWcAD1YqX7EkLIAA4Qe4GEXy3on8j7tZKAAwzBIBWowQEO UBg0+P///scGwQcAaABwBtEBHWAQOoAGtoRhaGBXNEAAMACAaMAGd9A3GYAGB3EDaJB+amF9 F+ECEPB9BbEGC5UCECABWiGCJIgQacABA2GCaiEBEOCBDyGDW5EGKGAQI/ACBqBbfjEBQkCB RfBGsTUBa0UQ/mcQCzAB4VYQCDABBJACQjABbwCAdPBGEnQBaVQQBDABxsMW0dcGLTAC9uUB G3AH9iUCazB391VfOFABNNhea9iGI8ABAVAAKZgAJ/CGIqADBrEGIvCGAqABgviG/h4AiDRY ACsgAIRkeoXoajkgADB4hwEQAoQYhwMAfBxwXygwAAOAAoRofgOBifdlAyNYAZ14X3EIAAdA iMxmiSHgAYS4Apt4h544AKr4hpooivf1AjBYEBxgAXegW4d4X4m4iXewiipIEAPgAfAiEGoY Acd4hoDoAgLQhgPBAcEoEEhoEBrgAxr4jQaxhAXRhE9IEFFIAE2ocwTRhJvChQfxhWG4FtHH ATLwfRVgAQTAZzQAAfxHaV8mEAaQgos4ECwAkABQXwCghxJAARDAbFJnAd04EAcAAfW4W/UH ATQwEAVAkQCwiA5JEBcpEC+4WwspJgI5EAWpgmlAAAMJ/gAgAAEUAJGfNxAJEJMDsZLfNoIX 2ZEEmYJsxQFRJxCDxZACwAYxeZAvGZMzSQE/yZIpCJESaZIVKRAckAMUUHxROZEw+JJ8ppNW SZIQ4Ioc6ZEgeZA7KSYDMQEQAAJwGZc1MAdlSY4FYY7v6IQGsY7ouJdSCADyaBD0eBsm5xwc MFquVpEKyZAeaZAjSBCLKSYOCZE98ItXCQA6YAMdwIopUJIEcZIiKZQWWZaJuZYpSRAjeZID AZEUoAEZAAPISIoCwZg9WQAXeV8ZIJQcAAN0WF/MhpRsWZuluZo0eZv2lZsPSZOfeZmHOZoF cZKq6YIVWZKeORCg+Zim2ZZv/rSd3BkEf7cEBMAA4jmeV2gQKzABPuAB4ymeMSCFfQmFfxmY XgiGhMl424iY0clWAal4CSkBNJh+AxCZDTmVECCbDaFgN3CRMRkAOQCDodl+AjECpJkGLWCa AsCfQpmfrHkQJsBDBXGhBMGCF9lrCYEAEFABSIkBBMGUFcmaI2oQEEmKHcCco6WgA8GgX3mZ n1mhzmmjAoGjIQkBLEAQ4kUQbhmXcRkEQlCWKgAB3MmdGmgQJ/AGT7qd7KiX8BmPXUgQgymG hVkQGWABCJYAFuCOFQABbnIHEFAC9gUDMEADdyAD/iUAHWABAVUCbBAAKxCRFZAGMnBfGEAB BlEA/mx6nDAwBCEgA5tZX2zwAve3AxyZADbwAv5FAGkAAWR2AxCQATCIpwGgpoUqAG5KAwNg ATwalCEyp/UFA3ZVEKBqXyUAASsQAhawqIwaoW/YASWQAJ76qvWFigVQqqcKAAWpArRqq0kJ ABXQAX9aXxiQA+64kzCAYIlqq406BKUarQahqeJVX5c6d4pqX9cKADTgpvYlgTZgpEn4o3QQ peO3APAKrxtQngehp/EKrzXgnhOwgwVxnloaYwPRA/TppfaZfW2hlpNRnRVhhRfQsA6bhQkI ACvgsA7rAxMQsQYBAhR7AWkwBxMwAmuwBBMAAxTbAR7rJu35BhvrpEIgx5aL8aUGqxYrUABy pqmDBRkzWwBrEAOkaRFV+kYQEAMD2YRPCgEecLMGwQBPKgQw0AZ9swAEYLHbyWhOuzhtAANV uJ1v0AHwZY8wG7NfUQPcyI1V+RjLOLbNCLbad3xq27bOB4JuG7f0BrdyW7d5Rrd2m7fRgRsg cRd6+7chBhhqoBBlcRaAe7jLIRd0kRByMRWI+7jCERZmgRYIARRMcbmYm7mau7mc27mc6xQN 4REg4bmkW7qme7qom7pCwROUC7mu63gBAQAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhUABIAPcAAP////f1//b29vX18e7v9+7u//Du8O3n+Obm7+Xl5t/l6+Df+Njl4d7d 8N7g597d4NPb5tnZ8dXU5tjX39XU1c7W383Y1MnW3MXW09PQ387O4s7N3sfO2MzMzMLN0MTE 1sXGxHz3fLPMvsDI1L3FzbzCxsW/18K/zb27xb290Ly8vHbsdru7uLa8yLO6v762x7i6trW0 z3Pmc7y0vruzuLW1xbS1tra2vbS0rq6zxK20vHPbc6y0s7etv6OytaC9pbWts2vcaq6qxLOv rXPWc62uvK2tra2ttaurqKOquqSrtrOos2vWa6aqra+kvqepqKymtWXUYqymr6imu6qmp6Sl taWlpaWlrZ+ktp6irGbMZqKcs5uopWrEaqaarXm6gaadpp6ct2PFY52crZyapaOVtaaRrKST o5mZmZmZmZmZmWO+Y5+VrZyVpJeXpV28XWW4Z1y7YJSTqZuMpVy4X2avc5KOn2mpeVq1Wmau ZpOLlI6MoI2Pko2NjWaldVqtWmSobICJmGibfFKxUWaZd02qUlelVmmVfYOEioWDlWaZZoWE hXePhlKlUmaVeGiKcV2aXIB9i3x9j1CaUHl8em2AeXp4hlWTWEyZTFWVVVeVZmmEZmd8b0qU SmGAZFGLUXRzh3Nzc3VzfHBxblqHWVWCX02MS2x0fXBrgm5yclCIT1p7Z3RsdWV2bEWLRUuE SWtsdFp2ZkKEQmtmdGZmZkh6RmZmZlJzW0x6UGRmdVlpZEJ5QmRebjx5PFZiaUdsVWJdYkZu Rjt1R09jVFxcbTpzOldaYlBlTllXWDxpST9lP0xbVjdtN1hPX1ZVVlNPXFNSVDNmM1BHYD9a Q0VPVU5NTU5JVktIV0pJSz9SSDFeMTVUNitYKzpMQD9HPTBQMEVDRkc8UkJCQilSKTRNOTpE OidMJz49Oy5BNzg6QTo6OSw/KyNIIy08MCFCITMzMx86Hxs3GyssLhkxGScnKRYqFiEiHhIm EhAhEA4bDgsXCwgQCAUJBQAIAAAAAGbMZiH/C05FVFNDQVBFMi4wAwEAAAAh+QQFSAD/ACwA AAAAUABIAAAI/wABAHjAYsiTgwgTKlzIsKHDhxATWiHDQoDABxQ6qLCBo6PHjyBDihxJsqTJ jkaMkFnExwBGChRUIDGCY4jNmzdr4tyZk6fPn0CD2kRiRQ8lYGhYdOhQogQII1aeWIl60MqV K1kkPrly8OrVLFGvSKFyxQqVJleakDW79QmSJgibwH1C5axcugflzn1i48giYMhoGWGhwogD AC/GpMWS9sgRLEcUNzlSJIuRLFWuFBGy5QjmJkp6QFEidnQPIJmlGNFsY0rKI1Bu2IAypQmQ IjlsLCmipAgUITaUTNHQYFG1as6e1LyiAIANK6stG6lSZXX1JlWg0JRr3ciQI1dWY/8psrqJ 9ypFbBhJcsQIlPZD3hvZXYQH5SI4bue4f39KBgSWiIMNNNAh8UQCAOTgRnjlGYFWSlegd5l5 V711hWNXTSFFFuGJ1UNkRwxxRRjkWWaDFE3QAMSFNhRRhQ03THHEDaLBKOMRFyhgiTrgVFPg EwgAcIMcaWGV1oNVYAZFE1lgh6JcVUxRhRKT4VBEZVIcoQQSUvhmhA7aTVnFEjxAUYQUUEAB RJkyStFXEfdNVgEClKgjjo9G8CWAACopgYVcWYTxZxO1PTEGFlQi4QMJGJDg4gcf1ODBBRlw MMIHJBjhwwQp6ICBC1zcEIEGcB4hxYW9AQHbWbvpcMQUU1z/oUQVEwhQ553QPXEDAARUAV1a Dl41XRVyRYihEhxUIMEHyH5QgQYt6HDBAhxcUAIGHBShAgY8GGFBBAt8kEV6EeoAZnpLQKGD fUfYAISZUHQAACJ24vmEDgEIUMSCDjY5BJMyCntZEWI1mkIEI3jwwQYkZEEGCRBwsAEHCtQg RwsV+FCCARuAS7AOZ96nZg7agewEECAvUQUHBCxSL3RWsACAAVNIdqis4DUxhlyOWTaGERWM UIQEC0TwAQYXaGBCBRyYkEERGkhwQw4boAABARlE0AAIo+nQl3a+FaHDEkc0UcQUXnt2QgH0 4pqnzARIYQV4WYC3hRIOSjZlv0ag/9BCFTdooIELLnygwQUb6ODCCVhUkUEHObRgwgY51FAD CScUgQR/KTWBww1OlH0lZUcg4cG877hthQq8VkGGeUQdkaTZDsq1M4XjIZEFFDxUsQWKWUzh YhhGIDGeDbLygJV2VPaFnnp82WD2DS4egRoWRnQgQNt4rg6AAlvsDMUVio1/BRRV3H4FouFN 0Vt2WEnR5RZcEgsEEFIkUYVqTdhQ3RIXqo0RZDdAWH2nce45wlYeBoA+pK57rEPAGciQpK8o BivuqwKioGADF/BGCUrwwRSEICW0jI82VMjC7rKkAxBW4V1FqIGr2uUY2YDHCFRyDFpU44YP NPCBMCtB6/+gQywctCgHKFABboCwhSuAwQ56kEQiEmGJU4hCFKyABSxoAYtZ8IIYvPCFL3hB C1rwIhewyAUqQMHGRLSBDGCYzA2EoIIb1CAFKsiBbHCWhdM5UHUgAAACXCeFF8wAClKoghwQ EQlUkBEYz7jGNbpRjmxYspLZ6IY3LjmNbJQDHd4oBzm8EcpyhBId5ShHOtIBjmu00hjEMAYr ECGJPWzhPTdAQWSuAAIB/LF7gXwAGbCnh1kQwxrSCMc72vGOb3xjG9OYRjCCUYtX1OISn1BF Ni/BzUtkopvc/IQ4x3kJVZjiFa/4RC1qEYxpbOOZ5EAHOtJxDWk0Ixd7uNIYagD/AD4AESqB HKQbcvEOcwijGJq4gx/EoIWGOvShEI2oRCdKUS3UwQ9+EAQuvmEPecCCQ0L0JyABUIAb8EIY jYhDEJgQhZZW9KUwjakWWtrSIGjBEK+gByiK4IEAiBSYAEjAGHARhZXK9KhIjWkQgmAKZIwh Bf38pxUCmQA7dCGpWH0oE7TAhK5q1atd3apEg/AIO2zghyMNgB3WkFWsMkEMjdBCIzrRiK3u YAdzbcQO/tCJSYgVolE4hB0sAAA9SDWQBFhrW7E6D38wQRbRyIc2dsCMTsiCGfooRieiUQ9z /NWhURCEHDgQ1ZEiYA9sXexRmTCOfohhBTuIxz5kUI9x/8hAG/roxQpkMA5/SDQKd7ADVH8K s0D69A2qPaoMeuHYTuwjGlyVBSZ2IAN44OMPzxXDZx3aBTTICw2HBUAAEkGH5Mp0B73gxw7g sQ9taEMG/DCHLMyRj0Zwgx/a4MZE12AHCpQWqAHYQxzMe1SGikEMeCgvQ9+AhzW8FcHllega 9nA64gJUvOSV6B82nNqG/iGuDvWHNlarBW74g6FtXUMiSGvhqYrXEniQqD9mXA86vKEXrnDF PnqB4n34oxg2fekaGlEMf+yjGJPoRYy1EAQZbHe/kThri40rCeRG1B/mwIQ/6OoPffwBH/7A RzRkoA9/8EMWMngpHZxr5E7MWP8fdGACPPKBCUPEQwu9uLOE95CB/xZXvIEY8JXH4Y584CEf M5aFO2bMj2K8AR4z7kWaJ7pcfphZG7Lwx6HZIYt++KMXWr6tbyWcCP9OGQACyPCVZ3yPaMzY H/PIxzyY6w9mhIDWaJaoDDJd6z+EINPauAc/6oEPVzRi0dy4x6gjmoc+XMDPF57XkiH6alY3 wsci/rU/7sGERph523TYgUNlgAdlWzquO+C1iGGNiXzEgxlt/q0j7AABaLs4wIKmdj1cXe0Z ayMEJnaHNvzRCEiHWRYOlUWZ/QEPb49D22IQdqzZ0Q9ZGIIfvZhoFAixBwnYO5DbizC1mUHr vtJaH/H/mLE5osGPELhDH/y27aL7EQ19uGMF++DGrf3xcnjweh8rgHTGf0uIREzg4wJBxLQf +mp2TEIGTS7yjOPRia7uAx6d6MQ9zKGFaDBhxOPAxyQ64Yp5MLkT8YCHNv7wdXbgwc35oOjG 9XCYUwPADiJ/aC96IYsd/FUGmOC7UbWgaHewgx3i3qpde6uPuTaUCTtYakOD4Pc/4FjuhLBD 3cMLADfkG6IyELdEiQDRuz4eol398NLbGlo7PADpACDD5wlMe41znAGwB8Psa8970DqiDEGy Owo63Pviz9QRU1gA7GNAfOPzPrBVMADsh+9840fBEVIYAFqBCoAONL/6WVW8/+9vYBFESJV1 AJhAF7p9j3jUQxZBBn9Mu+0Przc0Co84QQAAsIjzX+Sqb6AN8zAObCd/5xUPkVWAUVAJLxAk vwQz6DcBcMBVYlAPjRB/BvhSQYB441BXDVUJH0AA2weBAuEAyRAFTAYPKJaBMBUE7sAE5lBX UVAHluBxAhAJLwMVMgMAB8AIKChXLChTG+gO+IAHLFUHfDAB+4eDqoN+BMAFKOhVXGV8iid6 MvUGKBYFgOAGEhAABbAjbsMXIggAPxAFf7ALTrYGxRBWXCWF4pdUlrcCjcAODgZWYSVWUih5 MwUIYWAAAbAAopCDSHAFHgcAIhAE3uYKO0BsKzB2TP9AB5jgClogBpPwBpOwgvP3B1umZXDl Cg42Ca4Aiobgd321UpggCwylhVVAAAHgAKEgiFfwes5RCHjAav7ADp2gD/fADUUWD+7gZpnm gTLFBLUIa77VCOZwD94GabJlCNxQD/zgCsyAcSjmCE1gAATgioJoBX0GACcACLUYDdHgi+6w D+NgDsWwD67gD7vgD1omjPNXi73gYwFoDv6QaW7mCvwwjfPgDsUQDfNQD2/ABGtwCj1AUhvw im6jEj4EABTwBYPgD5MQAvdwD5iwj67gasz1ZZAGjzBFjASnBY2nD5CWaZnGXP+ID8WACZjg DmbHBH/QDCYgECRAC+fgNrr/Q1oAIAFfEAWT4GCNoFeN4AqYQAeNYIlM8AZ9hYkxRYlvEAQx ppSVOJVvcJRMYFmG4HhbZQjAsAEFYAAfAAs3iSeDmAIWcQCH8JSPp3h3OIVs6Fanx4biZ4dv GQTtMApdeAAxYJMLaQU5IIIDIAqX8INBiFRMMAn0EAkLUAANkANiuZBkcAUIEgBuQAp5UJhI FQRrsA7vsAfSxwBJMAtjCR2XQQayiALJQApdQJiYSVEw+QrrkA4+sCcegAWPiSerMQZCJEi5 8A2QkAdMsFJtyYJR0FU1pQWQoAzqYA/E4AACMAApsAW3SZrkYwMCEAAB4ALd0A7H8AqmcAmG YAiY/3CJLEVT5nme6Jme6klTeRCef4AHmfAL07AO9HANRXCdCjAFWZAKo1k8hLIFHaAACZAB Y8ALxnAN4SAN1JAN4IANw3AMw/Cgx4ALuBALq3ALv1AKq7ChnlAKt+AJnrAKsbAJnhALnrAJ q8AJm7AJsdAKLiqiujAMy2AMuqALz/AMxmAMouA4CNAAL4AGVxAK/bk5NTAGbtACHAApNpAF YzAGZPBGT4oGdjAHdtAGbDAHc8AGZpClXtAGbTAHXmAGZeAFXnClXjAGYyqmZgAGYLAFTgAG bCAHc2AGY1AFcMoGYEAFVRADNYACJsABNeAG98IKY/kExXMEKQAeVdADNf9gA0OAAzMBA3AC AzfAA0NAAy7AA5RKHjCQqTbAAz5gBDRwA+YiqUpgAy2iAzhAA/hBqTcAA0oEBIThAjDAAiww AyqQq6TqKkxaBTogpKrTBCdwAy9AMjWwHyxwrFPQqL3RAsGhR68yA60BHK8iG1DQAzcAG9h6 rS5AMrIBBDdwA/eDAjMABDTwAjUAAzMgGzYwrDaAAjmQHc+aCg+EBmTAB4iACKIQCleUCrAQ Cvy6r6cAC6kAsAArClrECgqrsKOQCqwQCqwwCqHQsA+bCv7asLDQsBrbsKGQCqOwsBBrsSKr Rf4KsFoEDvKgDtXAAotwFNUgDuoQs+dwDjFbszNhS7PqgLM3m7M0u7M5y7M9e7NCK7Qyq7NF G7Q+ew7vIA/0YA+UMAB8ABjVAA7iULVWe7VYm7Vau7Vc27Vee7XvYA/IgCAGgAbA4AzQcBxq u7Zs27Zu+7ZwG7dy27aUgCABAQAh+QQFUAD/ACwPAB0AMQALAAAI/wC1CBxIsKDBgwOZDBSD ECGTIAkVPiQI0aHCNWKCaBTzUGOQHTsQBnFVj2GQaLKYmIP3hwmTRvXwBGHXi1u+fPXq6cuH qR6+nfjqTYI3L+e4RnQO7ujlj6GMcftk3PPHTUYQTP7+yNDHrZc7d/7qmWOHdR67r+Y6+YvH zlw9f42UMnUKVUY+ePjGrWjkD8/WcUQE7pMVYgUeuCs07vX3ZoUMMfPMKSy4tKmWp1H1jduh LxpTv5pDauHXaweTP/5Sh11sSOGKePVEE6zMEfNWdiu05EsNmp1of8VCrtEmqzgmGXwNaWzE b57shJj2Sfenj52MffFkMBGzL6sMf/BkCFj0x0z8G3+9fvIjH49p6nprRHYqRr+XS1mdJveK toZJr/wCFdOIQpBFUwwz9GEyTy/MIPjGZA1pQURgEkKoxS6uXFZRhQMFodCEgUEkg3gRljgQ SCamWFBAACH5BAVYAP8ALA0AHQAzAAoAAAj/AP/9W1PMHyY69fz1WiOwoYwgQfA0msiwoUWB fyY2uvhvUqePnSb++6PPn8mT/vL9+deoWDFtIflFYxZPVsNiM4sJZLaPWbRo2ly61DZPm7af 2vS9Obnvnj5890ya23HUlax58zBhMmfzDZ5O8Fy5GsfO3T8xvdx1wjPJqixZkxr9gecOj7ti 7BodlfVmUq9ojcw1YtaLXydMvRqZnPTPqLlO5uK96dWJ6klZWhL6a9rrD7dijfTpE0ikETt9 MsXskIHvXyd/svzBE2M1iCx37P4RcQePnT88YvxxawRvXy9/9zDheePOnTkZ3JALlIUTU7TP WpgIV9yP2Qo8+ri9157HD5+YeP7mMXnT+h8/fv7iRd+HKYSYcfvqvanXvpdPbv+s0MkaWvDD jGbjNEKHP39g4g8TeLhyXHydFcMPN9H4w08vb2Ayjz/msKNNPrCpBSAeJ+GjhQwr+OcSM1qA GA08y5nU0yTuMPFhNP+8IQMzzj220T+9EAVPNHjs0xGGsvTSyy5M/HPiPT4ZYtNKtBni0kjR yNKSOf8wIctRPP6Dxz+Y6IVUPgCOlBY8cMIjy5ksTcLNPnDiw84a/MQT54V9wjPPPfXo4+Uu yNUDZ3eNYNIJYwEBACH5BAlYAP8ALAAAAABQAEgAAAj/AP8JHEiwoMGDCBMqXMiwocOHECNK nEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMK HZpTi9GjRwmO88dU37+kBhsJJEKESS94WPHhm5ePHVKoGr8iZcLkX1lz8OrVY+YOrFEx3O79 axQtWqdiYmTImsdNRhB9g8RuFItUzBsmMnr566RNFjd+TAiP0zJOjBhXsuLVK9ZpnLl65rT1 euo2I+GvO1b8GSf1j7Zifr8yMffnXpBGWmS4uqft3rhecQ2RLo1Ri0CxQZj80RzPHTxDvfSx m2eOrPEg0epp09eJnxZz+f5p/+tU7988TGK0RSZ+0fhwo0wauWMab57AcfnyxevnD96kP0Fg xw4TOzSGBzsraPPGClpow4w547Czg2BhHUcWgbIwVQweK4QAzz9MyRLCP67Mhw8dO+wgA1my rCEcN/i4M0lc9+gFTxAUmnYdHo24wk4n/pgTAo5asMOUP73goeIK9eBjCDPc/NGIGPCs8c8b eNwTTTG9xMOONn+4sx57FhnVCD9HHrkLE9rkc8+RDnaCxx/6pMnUOLJg4t48e7njHDc+5jgY M8w0YqihhpRn36GNFENoI8xEYwijf9STnBZv0BENpvrgs88aRSJF1KiklmrqqaimquqqrLbq 6quwxhYq66y01mrrrbjmquuuvPbq66/AyhoQADs= --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAAACjYSPGctxDJo00lEIk96U13U5HziGIrhZ 3JWSGVY2ESpnirraj0ujIVLr8TQ6TxEmBPpmQ+YJ51ztdMipEhe0ZK9LU8mLXVKLThl4hBaa mVcu8XNOf9nmcbi5ja+nYp62f/dkwsYH1dKF9Hfn9lLlJkXYVgfIqBZpBdn1M7nIR5h3Axlh NPGDWagCqqBRAAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAAAChoQPgZuhDKOclD3onMwo63Z1nuGNEVeJ 5WKaR6nBFNq9H+iqJL0rHF/T2VSPnOUCBO0amxCN18rBkDebLzYVopJQ6fQH/q5Yn2JISCTL xOHKj9mED63ma69anRmPyh59uGXnN3bH1lWIl6gERpdlRXKHocYnUrhkmZKQualHNbeZxyk6 GlEAADs= --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAAACiISPqcvtD6OcMVgLQqa8P41cBnhhZQai o7iSqcl+ytmKJ7bWWrnDfdxIjTZE4TDUO7yIm19TGeQthUamEnd8Dklb6ALHc9CA1ia3GzIz wNJKGUWFThM7L/0XhtSRquxeK2eHJEV2dWPz4oJoQweHNUhYpVPT10cDl7VVqNPm4fnpmAc6 ykHYUAAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACkISPaRHqD+NpErJ7UcNMA7pkyyc6VDdx mYpZJAt7cKuA3DuHd5qq+p4AhWqnm/BxGhWPMtqn1nMCJ7+SxrqxXm3RaCnLGuaq0+erQh6h qU+mK2majSXLMBLnM8Vjxw3+W5aXtoVC2MFlh4TltFdX+OfXJvhT5aVldmZmFPPHE+Qo+NgV IcqptqL2WYiy4nZQAAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACgoyPqcvt74AEalpZZ9AbL55RnZhYyIVu p8aB3ni8Jri+X3TVuYHKnh3b8WamYGrUQ6Z6pBKNKVT6ikaatFkFDq3bJfTKImK7IWPomexS j+dp0p2DUuTgMVL3rm33Hy2fe4cX5iTEpoaVdtYXZQbj2NEI+adlqLe4Q5cpBsHZ6fmZUAAA Ow== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODdhSAAOAIAAAP///wAAACwAAAAASAAOAAACc4yBicbqDyM8UrH2aN08hw5cmvWB5jZW Yumk55u40dqu7GJ7843XfCia/Ho+0k4XGwIvwqaTiDRCPcyo1CoDIpXJau2JUrq8Epo1CcqO S1wcGX2GT6/y7BLzjU/VvxH/PSfXlUfSx4PXhSjoEyQUtAa2VAAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACc4SPqWvhD2NgQB5bpab3de1R4JZEXOks JBJmI8h+0OlOH3226IwrGLOqvSYzj0mUkg2TvqUlNEIyla7ecNfjOIONTXF6zPJwYeF1KqTp zNydM8Mua79EmGqbhKbkbtZxfXflpwSIkoOm9gNkgnjYmFVCUQAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACZYSPqcvtz0Iw8lRwsZyZTg2G3nhVXXJC SKq27gvH8kzXTvmF5rejPPdbBXG6nAUo3HgyHaImtQkWWbaq1RjDWmHKaHH5M0ZzXh9OCVY4 v2XRCLRmD8e+t5yEJcb1c/v2DxgoiFAAADs= --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACH5BAAAAAAALAAAAABIAA4AAAKCBIKJdmqamGN00otzhbF1 HkgdBmniqE0jyp1hisKL+cyeCG9vVtK33zgJLzEbKWSUAW+WIDEZw0Vtq92zhXserZufDhR1 sYzhpBgK7h1rZGuZe4ZT50qvs1a/smnh7fB+N/fyQWfSdzWYxmYBtucB5wLUo/ioArJYKTNj ttTp+UlTAAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACkQSCqcZtwaCb50BE85IR36s5IEh9DXem nai0oVih6vxi9PMk2fmZu66rlG6d1mJiE1pkOOSOiHK5WDAhc2X9WZrBCOyK8xxfTSWvzDQa taOnJ/ykddXTKtnudSdn6zyVN+aUBLYUwzdF8geXOCRGFhQI6dM4pCGzlyehefXmh+RYVrk1 WsJBGHqaSRqHWtrWUAAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhUABLAPcAAP////f39/L08/Hz8fPy8/Py8u/v7+rt7Ojs6eHs7uvq6ubm5uHk5N7k 4Obe5t7e3tve2dnc29fd2NbW1s/W1M/U0MjY28bTyrbS28zMzMXLxr/Mw8XFxcXJysDFw73D vsW9xbfEvLXFtb2+vZbSr63Csri+u7W8t7y5uLW1vbW1tZy7xaK+rau1ta61rpu8pY3JpqW1 rYrCoKC3vK+wsa2trY+8oZ20pIm7naetqqWtpYLAnIO5l5mwpY22nH7AmaWmpaWlraGmoJGt n4K2mIO0lZ6lop2lnY6vm4iwl320lIKrkpyfoHmrknmrjpmZmZmZmZmZmZmZmXSrioybk4Kg pXmojHOoioyVkYyUjYeSi3Kbg4uMjG2cgIWMiWyaf4KMhHOUhGSefH6IgmuVe4SEhIWHiWWT eHyGgWmOeHqFfWqKdXaCeWONdWCJbnp+fF6IcHZ7e3F7dF+DblOObW14cVyGbHJycmF7bGxz cU2DZF1+amp0bld6ZlR5ZEp6X0d4XVNzYWZmZmZmZmZmZmZmZlFyXl5oYkxyXFRuX09tW1xk YVdhW0trW0toVVVgXExmV1hcW0piUkRfT1NaWUJjSlJaUktXUFFTUUJbS0pRUT1XSUlOTDZc RUJUSD5TRUlJSTdRREFJSD9JRThMQkJCQjROQDVIOztEQStJOjBCOCJJMzY6OyZEMzU4OiJB MS46Mio3LSg7MTMzMyQ8LyE6KRo2KCsvMycyKiQyKCgoKBoxIyMrJyEpIxgpICEjJyAgIBkh HRgfGgwnGRAkGBkZGRQaFhIWEw8PDwkUDgoKCgAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFFADMACwA AAAAUABLAAAI/wABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDQjwA4YDI kwUVVDhR44SGCgpQimSQg0qNERkeIHjQYYFMjwqEjAHiocOEAwGSPsgw4KdGAkDiPPnwoUOD AwKSJp1QIYDTix7eeDmhgkaGDBIOHBigVUCGCF8pGsgxRoUJJjk8TBjxYcEBAwS0KsgQMy7E CjpUZKjBxcgJDxoQ5NCgdkBgrxEyeDXMMMAIHRo8MBlDJYeKDxq45mCA4EABrQEqPODM8IQO CRm85GHzBIgLEx4qNGCSAQECA1m9IshgkjbCDFSAaxG0m4qQlqglUGCyoDVbrREmOP9H6IKK Dh1sIpmRk+WIaRMcKkxwUcG4gddeDVTwOb6gCus6PEEJF3J48YQOLjymwQMsLbAAW5cBwEBX /RHEAYA5HPIGGGpYV8NpGmRQAQUNDEBBB1oBEMAEDFQ40ANUHIHgGItgIQcW7v0GGYkTGDGG HAgkJRACE2xW4QBHHJiDEJRgwQYYTwiR4AcZTHBCGYt4oQICAgj0gHwtugiAC1ic5wIfcXjB RoymfeDCGIfEQQUFfwGAABK4cDFBBEb2p0EWQiCoBSNPsMcEgh+gEckYJ0jAQAEHiFDED6ug csIE/FX4AI465JADI1xsGGUOJggBBgcTPKDABT7sQEIbtAT/A8aCfToXABOH5nCCGnwQGCOC JoTIgAQvKMGDFZ4o44stoLiAqZj/deqCDpFwUYcWvbmgQgURlFAEDDhM0ksuvCgCSDBeWFUr bRVwqisfd6DR4RHbbpAED1s0soUTmaiSCRlt7IJJDhEU1t8BT8iYmIDWYuHSDVbwIIMqvnxB BizCSDLHHp3wgoUGDKzLWQ1KkrpImiqEsIQTOMjgiDKywKFIJob0kYgkiPjCBw0PNNcfdEB4 akIWlDDBQRM88KCEIsEE84kie/gRCCSSkJLJK6gcwaLIcRlwhBA5fHgCJW98kIQSTuwBizGT tNGHIpNM8sknkMCSSi9emNCdiyfI/+hCDR6AgYkKMYjRRRu9GKNIH45Isgkpp2SyBB6yECPI aiFr6neCJ2hihgZbnKHEKcI4QgowkH+yRx9brIHLMLA8cZTPttYAtgsuaPBGJB70IEYTmxzT izCxbKJIGp6Q4QkyivyhBg0cCJD5zzm64CYmT4DuR+LHqLKHG2lsAUkvp3ThwwYAeHBCAAsY UKEBgeKuWByCZDBELscgI8seinxCRizB6AMRWDCBAgBABSMIgAHC1J8PHKEGuNNADh7BhAts QhiICIQd7OAHXpDiCjYIQc+QAgQKBGAA0xtPA3J0ghNkoA6CqAAVWgEHP7ghF7nwgxJekIEG LIABEegAE/9G8AABKIB2znGBb8iSASFcggkUCIUpeHGMTYjBB5eCgAQ4gBMaoEEzBkChiybw wCllgA+LmAAVkkELPUzhBvGZgAdyMIIFBEAFZgiAAO7DgC71JwBmOgF9mCAKLESgEXRAAnw4 kIEcACEDFkjAA7jwAQD8ZQDGcZEGjKAtFUCGEZoYwSY9YALUPAELLVgBBiYAhCcI5C8GWKCL BnC7FlIAC5yIoQfodYI45CELVZgBChjTIgEsYI8I6KOLPiAEGrRQAyM4BCXqcJYTPOEYugDV E1RQAyAIAFLJzACJkEgbBBghB5yjABryEAk+fOABGqiBGZ5wExF5gQELRIAJIsD/AAZkqj8n kBITdXAtShxCEG9gghG4QAOcMOAJKDCOB2jwlwMc00ULOIK2ToCTOlCBCahgBR8ikYUyPOEE qGpkAwzQmwcZQC1iCmiCtuUkF2SBE6LgxBO8wAQaBOcB2kEYDQzwpQYYrD8Z3aj6+ECvHNzh ZGVggmIokCAPZIABDYhAHR9wUb4J9AQVUIMWPmSCHDyBVFYFAg1YpIH21aAC+SQnbTJaA2c2 kg/o1NEHIOMjLjQKUxTIwlG49E+Ago0GJnjhNm3DBCDUIANv0AQX0CKBBXTgDUfppx3FlFGz busIcjiBF+qQAw6oAAgmKANoSukBCRARNxJ4gPvEVCos/wjBAxfIwxEoUYo4cKGsVMqAEWgQ HqYwgAb+dJCY7HQEJrzBBRR4AhsEMQuytQQ+T1ADEDoQngOcAAgGOI4CCLBcEwAhqpDJwxPG ACgmSEkDmMAEFzpQAQmwFAsQWIACWrNcBTzQNLd8w13KIIQRqCAHWFiEETwgygqYlwF7YtFy AeDAHEDPA4I4Ah9EIYgsqGDBpATCCRiQmgPs5YcP4BpnvKbWS2lBDXn4hSsiYQS7eOAJZjDL BI6Sg57oFwET1sATnMkBDFMhD3KgQsK0pYlc0rcBDzCDB/opvQkHAGwmuNRoVXAELqAWCEZY BCewAJkQ+VUCAxBAA1TMmQocIf/LHPjAIqggCE1ElQZUGEENPhC2lXBLAWHc7ITDlmUKeIEP lNAFKijxBG194Alc8AA8MdUdAxTWRRA4qUs8sAg5UCJLSvaUJiIhYL1AgDURAPKEBeKCI9jS C4c4AhbAQCogZMEVqECDCymQqgjMZtUCeeiUOMAINXx6EagdQw6Y4ALIVODZl55w37Isw0uw 4ha34IMXNGqCbnsAMqoG9kAIwOwToOYRIcXEjYzQKRWQxQNNEXdBMsCELGcAC5pgwxi0gIUo deq2bF51DXTgbUYcQg37VnK/KyDvhGS0hRx4wij4gHA2xAEI0W74QO6NIBcsYtGHAEMGNM6Q CrA7oGoGwIJmnBMQACH5BAUUAMwALCQABAAKABIAAAhzAJkJZLZgwsCDzCKUQThQAbARDJkZ OPYrAEMDs5YJYrhARZxlKBAyCAmqlMgazB78qnCQAUpmglS0fIkl5ECXArMYHHgApYInFplR GDFCpocMAu8oW6bsCbMDArksm7pMyMFSVIsxOEjD1a1ILBEe2MowIAAh+QQFFADMACw1AAoA DAASAAAIjgCZCRTIgcbAgwMzUEKIkMGyhQwFRrgDjFNEZh0EBdC1KOKDZVgMGOvAkAGoZRzi mGHYgQkQYG+eMJxQzICQZSNKAtMVAFQNhhlycAFlRibCDAZrFMtxcEEEDj+ZlenILECcYsqA MWVGQBADZneWiV0GRGAALAsWFBura4HACmWZZbnF8cHAEW4FLvgaMSAAIfkECRQAzAAsAAAA AFAASwAACN0AmQkcSLCgwYMIEypcyLChw4cQIwpcMEGixYsYI5TByLEjQwXARngcSVKggWO/ ApRcidHArGWCWMqMuEBFnGUoZupkyCAnqFI7gyJkUIPZg19CkxIkKjCmUqVMmWF5CrUosyxU kx4oquBJ1p0URoxQwcxDhq8z7yhbpszrAbQyuSybu0wI3Jml6BZjcFcmDVe3IlXoO/MAX8KI EytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4 c+vezbu379/Ag1cOCAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 10: 6:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from directcommunications.net (mailgate.bridgetrading.com [62.49.201.178]) by hub.freebsd.org (Postfix) with ESMTP id 7F90637B414; Wed, 22 Aug 2001 09:52:45 -0700 (PDT) (envelope-from owner-ringtones@mobiledirect.uk.com) Received: from localhost (mail@localhost) by directcommunications.net (8.11.0/8.11.0) with SMTP id f7MGqQ332067; Wed, 22 Aug 2001 17:52:26 +0100 X-Authentication-Warning: hercules.bti.com: mail owned process doing -bs Received: by hercules.bti.com (bulk_mailer v1.13); Wed, 22 Aug 2001 17:44:45 +0100 Received: from mobiledirect.uk.com (aries.bti.com [10.54.1.1]) by directcommunications.net (8.11.0/8.11.0) with ESMTP id f7MGiiU01504 for ; Wed, 22 Aug 2001 17:44:44 +0100 Message-ID: <3B83E168.2090106@mobiledirect.uk.com> Date: Wed, 22 Aug 2001 17:44:24 +0100 From: Mobile Ringtones User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010817 X-Accept-Language: en-us MIME-Version: 1.0 To: ringtones@mobiledirect.uk.com Subject: Ringtones and Logos Content-Type: multipart/related; boundary="------------050200090204050702040306" 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 --------------050200090204050702040306 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit newlogo




Personalise You Nokia with these great Logos!!!

Picture of Logo

Picture of BITCH
Picture of HOPE
Picture of Bomb
Picture of Dragon
Picture of BEER
Bitch
21692
Hope
21716
Sex Bomb
21740
Dragon 1
20110
Love Beer
20203
Picture of Fcuk
Picture of eyes
Picture of Trust
Picture ot rizla
Picture of Simpsons
fcuk
21951
Loving Eyes 20142
Trust No One 20409
Rizla
21256 
The Simpsons 20399



Call Now ON  "0906 400 2144"

Quote the 5 digit number and your logo / Ringtone will be sent immediately!!
 For many more please visit www.mobiledirect.uk.com




Get Your Mobile Rocking with these great Ringtones!!!

Picture of ringtones

Description
Code
Listen
Baha Men - Who let the dogs out
10138
Bob the Builder - Can We Fix It?
11107
Shaggy Feat Rikrok - It Wasn't Me
11762
The Simpsons
10009
James Bond Theme
10000
Star Wars Imperial March
10085


Please note: the call costs £1.50 per minute and the average call length is 2 minutes. Please ask bill payer for permission. Calls from mobiles cost more depending on service. The following phones receive both logos and tones - Nokia 3210, 3310,6090, 6110, 6130, 6150, 6210, 6250, 7110, 8110i, 8210, 8810, 8850, 9000i and 9110. Nokia models: 402 and 51XX receive logos only. Motorola T250, T2288, V50, V100, V2288, V8088 receive ring tones only. Please make sure that your mobile is listed here before ordering. Mobile Direct reserves the right not to refund your money if your phone is not listed here. If you experience any problem, call Customer Service on 0800 015 1175. Orders normally sent immediately, depending on network.

For hundreds more ringtones and logos just click on to www.mobiledirect.uk.com - pass this on to a friend or stick it on the notice board

Important Notice: If you do not wish to receive any more emails, please mail us on majordomo@mobiledirect.uk.com and click "send." and your address will removed


--------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhiAFAAPcAAP////39/Z+fn/n5+ZycnO7u7tXV1b29verq6vv7+/f399vb27GxsX9/ f2NjY7a2tnx8fPT09M/Pz2RkZOHh4fDw8IWFhY6OjpmZmZubm/Ly8tjY2KysrIuLi6Kiot3d 3cbGxtfX16SkpLOzs9HR0ZSUlMjIyLm5uaqqqu3t7dPT0+Pj4+fn56amps3NzYCAgIeHh6Cg oIKCgsPDw+Xl5cTExJKSkq6urqioqImJid7e3sDAwFVVVZeXl3FxcWdnZ/74+bq6umlpacvL yywsLHZ2duUsTB4eHkhISPEsT09PT2FhYXR0dFZWVj09PVBQUCMjI1paWisrKzQ0NM3NtRwc HCQkJAcHBzs7O0VFRScnJzExMQgICO8AKhYWFg4ODgAAAA0NDRAQEBISEgUFBd4AJwICAuU5 V3l5eY2NjdPTvunp6ZCQkLW1tfz8+m5ububm2uzs40dHR2tra3Nzc9bWw+wsTr6+vhoaGlNT U3p6euMsTPb28RkZGS4uLjIyMu4CLNKvtQsLCykpKUBAQENDQ2xsbO4sTv77/BUVFSAgIDc3 Nzg4OEtLS0xMTFlZWVxcXOMkReMlRucsTegsTfEpTPErTvorUO85Wu9QbOpbdNCts9CvteTG zOvDyv75+v7+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAiAFAAAAI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatwI0Q2cOlRCihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz0qwDx01D Pmp0Ch1KtKjRo0iTKl16Uw2fhW6CqonDsarVq1izat3KtavXhHGk+kwIh4qasV/Tql3Ltq3b t1ijUoGjMChVuHjz6t3Lt2/GOFTqKAzpt7Dhw4gTfyWckLHix5AjS54MwPFBy5Qza97MWSvm gp87ix5NuvRlKoNRm17NunXm0ANhu55Nu3Zb2ZVV297Nu7dn3ad9Cx9OnCJu3MWTKxd+HPjy 59B5N48IqLr164AIXh+I3eB27diz/nMP370gefPfwVcHQD79eOsQyzd0j/B8/fD35aOHX3VN Dx9LOCDggA4sQYcHKRgUQQxFEEiggTEkKNAQAi6RhkMJQBDgHAjEEKADKkDkAgxLfOjggzCA 5pyK1LXHH3sv4qeeeAK5+J6NN9oHI33bubhejvTlF6SQCvlII5Av1ujjjPpZFEEPeIAh5ZRU TkmECKAIBAoOWlTppZR+CCCQCFM64RAoVUy5gANTjtAQKCM0QsaXdPrBYmMrLmTkj+npuCON Riq5pKCD+tnjoIQ2edChP+qZ5H6I/qnjnoC2p9EPdGZKgEAwZEqnDACgMKUcZx6hpiFtNtSA p3ROcSdC/sh5tyehSM6YqH2z3oqrjLQGquuji/IHbLCNyuqrpJPmGmlFOiQypRhHHCHIlGNE K8aUVawBChRTXhHtt+BOK6UgLIwwKoY5+OBDEQVgKqWbC40w55RhgGvvt1U88Wpw8T36XZ/J 8snjkbRCWmx3lvY67I3gMfRvsQkNiSyTiaJ3K8XuQUxRGlMWskIEEaAxZQ8gbzDIlBlIgO0M ILfscgh9tPnAlEhQtESqCzVBZRUhKODzz0ADva9BsUJq9J9IVrqeouwZS7CkBiPbKKNP29ri 0hoTSSzECA8pXpNdZ40RBCMP1KmUmwqks5Q5mDDlBAshMWUbM0uZBSh45423/gIBEBSABDWA YAIoN7/L0NpSLgGA3ozrTXSesUEesb9Txwjfw1iLvbXTm1OtMI5S9yvx5qQbPXrBpvOa0apS XigQ62CkDQDiHbjw9kJyTPlA3WAIQsTvwP/uhxMwIKClH2aQIcgHc+CsEA9UjuFH8NT/LoUU MwytvaOIApz590gfzbD4tlKdnfmqJ+xwkFWjTj7D7F8+LOZMTwT7BQPBLjv0UtY+pQO40x3v WAWGPqQIFCcDAxmY57yE8I+AVWrD9iJ3NT+FL3yeix/XgOU1+QkMfMf61Xz00z73WS11GvMc 50SIkfvlb0r7m5L/pARAheROSruDIJXYAAApSIkL/gw03EIeqEMhUhBPFVSU975mKQ0SzImd E1YTl6WrIk2xhBd83+eepsL3WdB+U8Lf62A4kAfOEAxwU4jccMi7KkxgAg6awA/+MCUtVMAP PwwiGO7AECJq4QdwPJGDQkSQ6YjufAOrnCLDtsFGcnF+HlQaIytoxQ+eTmId/N4TI1k6LUrE hWNEWxllWIMpKU6Nc+OdIxISAUWMiwR0BAMQmyclPi4kD1T6gXEklxtKZvGCGZMRCSmXwkSC r1ang9EJV1ixSrYPbPQ7kvmipszxWQSUANDfKNm2gSkpIgYhCIEKxknODYzAWVIKAu+cYIB2 urOdGyAAOsOwgS1I6QoU/qDDlJRgAnGS858hAMAjdiaCDbzzoO0MwQYmKJCinTCYi2SSJUFn wl+VB6LoG6b6mPnLre3qWJSy6BJVRxFsalMgD0yRFajEhSu49KVX4AKVvrACc0nJDDCFqUzL pAA8guEKHwjBThXY0py61AsJGIG4plRUo8LUCgzt5SFzZE1jLvKLmSwUMSNpqI06jaIeFWau RCpJ0IGVImSTkhgBkNbYDQRxDQBADIoopRsA4AZ0FcMMQOFTMgQUVQQURAUAQCa6ggEPUXWo NaEGzK0ezKsVJetiJxbCsxoMshKVTwgtelmNkpQiepiS6wAQWlEKRAlT0sOYprBUOnFhCj0Q /kgLdBgGJ/BxW1MiAQAiAAFFmMFTZJAQBxrRh3kR0AuJ5WUnMWi5Yjq2hJckqRMRedb6fVWS kwPrF4GUXUwmEyIhwIAAMhBQgYRXAARYqEB2kAEBYKC8i9vADQgggPraF703WECWBEIB+taX AAAOMAEykIEbfKBvAEgABzAA4AIMRAMziEEGBCxgDwyAICm4w4ApzGEMxCC50QlxaUABhBIT hMQmPnGJEdEQRHyixPudjCFFTOPJZKISSUiCHYywByPYIcc6nkSPDwFkO0hiEkaYBJGBzGQm U4LHPs6xJS7hCVBEoAAJGAjeFjeAFERAy6BIQQo0MJAIrADBGqgA/ijSvN8AtLlveCuAl3db ACvXGcQ1zrNVLmwVSZThz4AOtKAHTehCG7oLnDAQAZYAgwQkoAkfJkAjBJCGJei2CHmIAQH4 qIAlMCEGStjUHXKABQgwYL8wmMKFIEAHAKRBDgC2KwhKgAUm4IDPR4SVcgeCaz37Wi2TMLSw h01sQAMiEIrgoblqAAAvpOgNixAIHh4BgEIQIgAITkMVEvSCNwhEZQwgCCS+YIVHEwIAE1DE ABAMgBSAIbaPS82v512YYBf73vj+87H9EFsNkCEDADhCivSABz0wwQkSVEIVGkCALC2i1QUJ ARkkOJA8MEEIS4hCIwDwhi80oHgCSQEZ/mRXSF4qlt4o54q9881yYe8b4CsAg12rYAEA0AEK nfowAOQghy3PLg8CWUENskQCMrhpv0qAgMQVsXEhKAIUWRZIAcgAbzynXMTs5kskWs71Qndh E39AAgSeEAUEJIDmNmfEXaGwqUZAQQYv8AAAQrAIC02hAUSfuM3t+gQfAMAHYAD6GxLxAhj0 IMtTr3rJ5X31xrdFE2eIvOQnT/nKW/7ymMdEJ1xwAxGYQEs7+AAANgACgdSAjyQYQQxiYMsU xCANLnjwCRK0gwUAwAUBBcUDYr8BBrRABCPIEihOsAJ+6drxyE8+V2as/OY7HyPMf770p++Q 6FP/+thfPBI5/rKBAzjYIC44AQDWcAD1YqX7EkLIAA4Qe4GEXy3on8j7tZKAAwzBIBWowQEO UBg0+P///scGwQcAaABwBtEBHWAQOoAGtoRhaGBXNEAAMACAaMAGd9A3GYAGB3EDaJB+amF9 F+ECEPB9BbEGC5UCECABWiGCJIgQacABA2GCaiEBEOCBDyGDW5EGKGAQI/ACBqBbfjEBQkCB RfBGsTUBa0UQ/mcQCzAB4VYQCDABBJACQjABbwCAdPBGEnQBaVQQBDABxsMW0dcGLTAC9uUB G3AH9iUCazB391VfOFABNNhea9iGI8ABAVAAKZgAJ/CGIqADBrEGIvCGAqABgviG/h4AiDRY ACsgAIRkeoXoajkgADB4hwEQAoQYhwMAfBxwXygwAAOAAoRofgOBifdlAyNYAZ14X3EIAAdA iMxmiSHgAYS4Apt4h544AKr4hpooivf1AjBYEBxgAXegW4d4X4m4iXewiipIEAPgAfAiEGoY Acd4hoDoAgLQhgPBAcEoEEhoEBrgAxr4jQaxhAXRhE9IEFFIAE2ocwTRhJvChQfxhWG4FtHH ATLwfRVgAQTAZzQAAfxHaV8mEAaQgos4ECwAkABQXwCghxJAARDAbFJnAd04EAcAAfW4W/UH ATQwEAVAkQCwiA5JEBcpEC+4WwspJgI5EAWpgmlAAAMJ/gAgAAEUAJGfNxAJEJMDsZLfNoIX 2ZEEmYJsxQFRJxCDxZACwAYxeZAvGZMzSQE/yZIpCJESaZIVKRAckAMUUHxROZEw+JJ8ppNW SZIQ4Ioc6ZEgeZA7KSYDMQEQAAJwGZc1MAdlSY4FYY7v6IQGsY7ouJdSCADyaBD0eBsm5xwc MFquVpEKyZAeaZAjSBCLKSYOCZE98ItXCQA6YAMdwIopUJIEcZIiKZQWWZaJuZYpSRAjeZID AZEUoAEZAAPISIoCwZg9WQAXeV8ZIJQcAAN0WF/MhpRsWZuluZo0eZv2lZsPSZOfeZmHOZoF cZKq6YIVWZKeORCg+Zim2ZZv/rSd3BkEf7cEBMAA4jmeV2gQKzABPuAB4ymeMSCFfQmFfxmY XgiGhMl424iY0clWAal4CSkBNJh+AxCZDTmVECCbDaFgN3CRMRkAOQCDodl+AjECpJkGLWCa AsCfQpmfrHkQJsBDBXGhBMGCF9lrCYEAEFABSIkBBMGUFcmaI2oQEEmKHcCco6WgA8GgX3mZ n1mhzmmjAoGjIQkBLEAQ4kUQbhmXcRkEQlCWKgAB3MmdGmgQJ/AGT7qd7KiX8BmPXUgQgymG hVkQGWABCJYAFuCOFQABbnIHEFAC9gUDMEADdyAD/iUAHWABAVUCbBAAKxCRFZAGMnBfGEAB BlEA/mx6nDAwBCEgA5tZX2zwAve3AxyZADbwAv5FAGkAAWR2AxCQATCIpwGgpoUqAG5KAwNg ATwalCEyp/UFA3ZVEKBqXyUAASsQAhawqIwaoW/YASWQAJ76qvWFigVQqqcKAAWpArRqq0kJ ABXQAX9aXxiQA+64kzCAYIlqq406BKUarQahqeJVX5c6d4pqX9cKADTgpvYlgTZgpEn4o3QQ peO3APAKrxtQngehp/EKrzXgnhOwgwVxnloaYwPRA/TppfaZfW2hlpNRnRVhhRfQsA6bhQkI ACvgsA7rAxMQsQYBAhR7AWkwBxMwAmuwBBMAAxTbAR7rJu35BhvrpEIgx5aL8aUGqxYrUABy pqmDBRkzWwBrEAOkaRFV+kYQEAMD2YRPCgEecLMGwQBPKgQw0AZ9swAEYLHbyWhOuzhtAANV uJ1v0AHwZY8wG7NfUQPcyI1V+RjLOLbNCLbad3xq27bOB4JuG7f0BrdyW7d5Rrd2m7fRgRsg cRd6+7chBhhqoBBlcRaAe7jLIRd0kRByMRWI+7jCERZmgRYIARRMcbmYm7mau7mc27mc6xQN 4REg4bmkW7qme7qom7pCwROUC7mu63gBAQAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhUABIAPcAAP////f1//b29vX18e7v9+7u//Du8O3n+Obm7+Xl5t/l6+Df+Njl4d7d 8N7g597d4NPb5tnZ8dXU5tjX39XU1c7W383Y1MnW3MXW09PQ387O4s7N3sfO2MzMzMLN0MTE 1sXGxHz3fLPMvsDI1L3FzbzCxsW/18K/zb27xb290Ly8vHbsdru7uLa8yLO6v762x7i6trW0 z3Pmc7y0vruzuLW1xbS1tra2vbS0rq6zxK20vHPbc6y0s7etv6OytaC9pbWts2vcaq6qxLOv rXPWc62uvK2tra2ttaurqKOquqSrtrOos2vWa6aqra+kvqepqKymtWXUYqymr6imu6qmp6Sl taWlpaWlrZ+ktp6irGbMZqKcs5uopWrEaqaarXm6gaadpp6ct2PFY52crZyapaOVtaaRrKST o5mZmZmZmZmZmWO+Y5+VrZyVpJeXpV28XWW4Z1y7YJSTqZuMpVy4X2avc5KOn2mpeVq1Wmau ZpOLlI6MoI2Pko2NjWaldVqtWmSobICJmGibfFKxUWaZd02qUlelVmmVfYOEioWDlWaZZoWE hXePhlKlUmaVeGiKcV2aXIB9i3x9j1CaUHl8em2AeXp4hlWTWEyZTFWVVVeVZmmEZmd8b0qU SmGAZFGLUXRzh3Nzc3VzfHBxblqHWVWCX02MS2x0fXBrgm5yclCIT1p7Z3RsdWV2bEWLRUuE SWtsdFp2ZkKEQmtmdGZmZkh6RmZmZlJzW0x6UGRmdVlpZEJ5QmRebjx5PFZiaUdsVWJdYkZu Rjt1R09jVFxcbTpzOldaYlBlTllXWDxpST9lP0xbVjdtN1hPX1ZVVlNPXFNSVDNmM1BHYD9a Q0VPVU5NTU5JVktIV0pJSz9SSDFeMTVUNitYKzpMQD9HPTBQMEVDRkc8UkJCQilSKTRNOTpE OidMJz49Oy5BNzg6QTo6OSw/KyNIIy08MCFCITMzMx86Hxs3GyssLhkxGScnKRYqFiEiHhIm EhAhEA4bDgsXCwgQCAUJBQAIAAAAAGbMZiH/C05FVFNDQVBFMi4wAwEAAAAh+QQFSAD/ACwA AAAAUABIAAAI/wABAHjAYsiTgwgTKlzIsKHDhxATWiHDQoDABxQ6qLCBo6PHjyBDihxJsqTJ jkaMkFnExwBGChRUIDGCY4jNmzdr4tyZk6fPn0CD2kRiRQ8lYGhYdOhQogQII1aeWIl60MqV K1kkPrly8OrVLFGvSKFyxQqVJleakDW79QmSJgibwH1C5axcugflzn1i48giYMhoGWGhwogD AC/GpMWS9sgRLEcUNzlSJIuRLFWuFBGy5QjmJkp6QFEidnQPIJmlGNFsY0rKI1Bu2IAypQmQ IjlsLCmipAgUITaUTNHQYFG1as6e1LyiAIANK6stG6lSZXX1JlWg0JRr3ciQI1dWY/8psrqJ 9ypFbBhJcsQIlPZD3hvZXYQH5SI4bue4f39KBgSWiIMNNNAh8UQCAOTgRnjlGYFWSlegd5l5 V711hWNXTSFFFuGJ1UNkRwxxRRjkWWaDFE3QAMSFNhRRhQ03THHEDaLBKOMRFyhgiTrgVFPg EwgAcIMcaWGV1oNVYAZFE1lgh6JcVUxRhRKT4VBEZVIcoQQSUvhmhA7aTVnFEjxAUYQUUEAB RJkyStFXEfdNVgEClKgjjo9G8CWAACopgYVcWYTxZxO1PTEGFlQi4QMJGJDg4gcf1ODBBRlw MMIHJBjhwwQp6ICBC1zcEIEGcB4hxYW9AQHbWbvpcMQUU1z/oUQVEwhQ553QPXEDAARUAV1a Dl41XRVyRYihEhxUIMEHyH5QgQYt6HDBAhxcUAIGHBShAgY8GGFBBAt8kEV6EeoAZnpLQKGD fUfYAISZUHQAACJ24vmEDgEIUMSCDjY5BJMyCntZEWI1mkIEI3jwwQYkZEEGCRBwsAEHCtQg RwsV+FCCARuAS7AOZ96nZg7agewEECAvUQUHBCxSL3RWsACAAVNIdqis4DUxhlyOWTaGERWM UIQEC0TwAQYXaGBCBRyYkEERGkhwQw4boAABARlE0AAIo+nQl3a+FaHDEkc0UcQUXnt2QgH0 4pqnzARIYQV4WYC3hRIOSjZlv0ag/9BCFTdooIELLnygwQUb6ODCCVhUkUEHObRgwgY51FAD CScUgQR/KTWBww1OlH0lZUcg4cG877hthQq8VkGGeUQdkaTZDsq1M4XjIZEFFDxUsQWKWUzh YhhGIDGeDbLygJV2VPaFnnp82WD2DS4egRoWRnQgQNt4rg6AAlvsDMUVio1/BRRV3H4FouFN 0Vt2WEnR5RZcEgsEEFIkUYVqTdhQ3RIXqo0RZDdAWH2nce45wlYeBoA+pK57rEPAGciQpK8o BivuqwKioGADF/BGCUrwwRSEICW0jI82VMjC7rKkAxBW4V1FqIGr2uUY2YDHCFRyDFpU44YP NPCBMCtB6/+gQywctCgHKFABboCwhSuAwQ56kEQiEmGJU4hCFKyABSxoAYtZ8IIYvPCFL3hB C1rwIhewyAUqQMHGRLSBDGCYzA2EoIIb1CAFKsiBbHCWhdM5UHUgAAACXCeFF8wAClKoghwQ EQlUkBEYz7jGNbpRjmxYspLZ6IY3LjmNbJQDHd4oBzm8EcpyhBId5ShHOtIBjmu00hjEMAYr ECGJPWzhPTdAQWSuAAIB/LF7gXwAGbCnh1kQwxrSCMc72vGOb3xjG9OYRjCCUYtX1OISn1BF Ni/BzUtkopvc/IQ4x3kJVZjiFa/4RC1qEYxpbOOZ5EAHOtJxDWk0Ixd7uNIYagD/AD4AESqB HKQbcvEOcwijGJq4gx/EoIWGOvShEI2oRCdKUS3UwQ9+EAQuvmEPecCCQ0L0JyABUIAb8EIY jYhDEJgQhZZW9KUwjakWWtrSIGjBEK+gByiK4IEAiBSYAEjAGHARhZXK9KhIjWkQgmAKZIwh Bf38pxUCmQA7dCGpWH0oE7TAhK5q1atd3apEg/AIO2zghyMNgB3WkFWsMkEMjdBCIzrRiK3u YAdzbcQO/tCJSYgVolE4hB0sAAA9SDWQBFhrW7E6D38wQRbRyIc2dsCMTsiCGfooRieiUQ9z /NWhURCEHDgQ1ZEiYA9sXexRmTCOfohhBTuIxz5kUI9x/8hAG/roxQpkMA5/SDQKd7ADVH8K s0D69A2qPaoMeuHYTuwjGlyVBSZ2IAN44OMPzxXDZx3aBTTICw2HBUAAEkGH5Mp0B73gxw7g sQ9taEMG/DCHLMyRj0Zwgx/a4MZE12AHCpQWqAHYQxzMe1SGikEMeCgvQ9+AhzW8FcHllega 9nA64gJUvOSV6B82nNqG/iGuDvWHNlarBW74g6FtXUMiSGvhqYrXEniQqD9mXA86vKEXrnDF PnqB4n34oxg2fekaGlEMf+yjGJPoRYy1EAQZbHe/kThri40rCeRG1B/mwIQ/6OoPffwBH/7A RzRkoA9/8EMWMngpHZxr5E7MWP8fdGACPPKBCUPEQwu9uLOE95CB/xZXvIEY8JXH4Y584CEf M5aFO2bMj2K8AR4z7kWaJ7pcfphZG7Lwx6HZIYt++KMXWr6tbyWcCP9OGQACyPCVZ3yPaMzY H/PIxzyY6w9mhIDWaJaoDDJd6z+EINPauAc/6oEPVzRi0dy4x6gjmoc+XMDPF57XkiH6alY3 wsci/rU/7sGERph523TYgUNlgAdlWzquO+C1iGGNiXzEgxlt/q0j7AABaLs4wIKmdj1cXe0Z ayMEJnaHNvzRCEiHWRYOlUWZ/QEPb49D22IQdqzZ0Q9ZGIIfvZhoFAixBwnYO5DbizC1mUHr vtJaH/H/mLE5osGPELhDH/y27aL7EQ19uGMF++DGrf3xcnjweh8rgHTGf0uIREzg4wJBxLQf +mp2TEIGTS7yjOPRia7uAx6d6MQ9zKGFaDBhxOPAxyQ64Yp5MLkT8YCHNv7wdXbgwc35oOjG 9XCYUwPADiJ/aC96IYsd/FUGmOC7UbWgaHewgx3i3qpde6uPuTaUCTtYakOD4Pc/4FjuhLBD 3cMLADfkG6IyELdEiQDRuz4eol398NLbGlo7PADpACDD5wlMe41znAGwB8Psa8970DqiDEGy Owo63Pviz9QRU1gA7GNAfOPzPrBVMADsh+9840fBEVIYAFqBCoAONL/6WVW8/+9vYBFESJV1 AJhAF7p9j3jUQxZBBn9Mu+0Przc0Co84QQAAsIjzX+Sqb6AN8zAObCd/5xUPkVWAUVAJLxAk vwQz6DcBcMBVYlAPjRB/BvhSQYB441BXDVUJH0AA2weBAuEAyRAFTAYPKJaBMBUE7sAE5lBX UVAHluBxAhAJLwMVMgMAB8AIKChXLChTG+gO+IAHLFUHfDAB+4eDqoN+BMAFKOhVXGV8iid6 MvUGKBYFgOAGEhAABbAjbsMXIggAPxAFf7ALTrYGxRBWXCWF4pdUlrcCjcAODgZWYSVWUih5 MwUIYWAAAbAAopCDSHAFHgcAIhAE3uYKO0BsKzB2TP9AB5jgClogBpPwBpOwgvP3B1umZXDl Cg42Ca4Aiobgd321UpggCwylhVVAAAHgAKEgiFfwes5RCHjAav7ADp2gD/fADUUWD+7gZpnm gTLFBLUIa77VCOZwD94GabJlCNxQD/zgCsyAcSjmCE1gAATgioJoBX0GACcACLUYDdHgi+6w D+NgDsWwD67gD7vgD1omjPNXi73gYwFoDv6QaW7mCvwwjfPgDsUQDfNQD2/ABGtwCj1AUhvw im6jEj4EABTwBYPgD5MQAvdwD5iwj67gasz1ZZAGjzBFjASnBY2nD5CWaZnGXP+ID8WACZjg DmbHBH/QDCYgECRAC+fgNrr/Q1oAIAFfEAWT4GCNoFeN4AqYQAeNYIlM8AZ9hYkxRYlvEAQx ppSVOJVvcJRMYFmG4HhbZQjAsAEFYAAfAAs3iSeDmAIWcQCH8JSPp3h3OIVs6Fanx4biZ4dv GQTtMApdeAAxYJMLaQU5IIIDIAqX8INBiFRMMAn0EAkLUAANkANiuZBkcAUIEgBuQAp5UJhI FQRrsA7vsAfSxwBJMAtjCR2XQQayiALJQApdQJiYSVEw+QrrkA4+sCcegAWPiSerMQZCJEi5 8A2QkAdMsFJtyYJR0FU1pQWQoAzqYA/E4AACMAApsAW3SZrkYwMCEAAB4ALd0A7H8AqmcAmG YAiY/3CJLEVT5nme6Jme6klTeRCef4AHmfAL07AO9HANRXCdCjAFWZAKo1k8hLIFHaAACZAB Y8ALxnAN4SAN1JAN4IANw3AMw/Cgx4ALuBALq3ALv1AKq7ChnlAKt+AJnrAKsbAJnhALnrAJ q8AJm7AJsdAKLiqiujAMy2AMuqALz/AMxmAMouA4CNAAL4AGVxAK/bk5NTAGbtACHAApNpAF YzAGZPBGT4oGdjAHdtAGbDAHc8AGZpClXtAGbTAHXmAGZeAFXnClXjAGYyqmZgAGYLAFTgAG bCAHc2AGY1AFcMoGYEAFVRADNYACJsABNeAG98IKY/kExXMEKQAeVdADNf9gA0OAAzMBA3AC AzfAA0NAAy7AA5RKHjCQqTbAAz5gBDRwA+YiqUpgAy2iAzhAA/hBqTcAA0oEBIThAjDAAiww AyqQq6TqKkxaBTogpKrTBCdwAy9AMjWwHyxwrFPQqL3RAsGhR68yA60BHK8iG1DQAzcAG9h6 rS5AMrIBBDdwA/eDAjMABDTwAjUAAzMgGzYwrDaAAjmQHc+aCg+EBmTAB4iACKIQCleUCrAQ Cvy6r6cAC6kAsAArClrECgqrsKOQCqwQCqwwCqHQsA+bCv7asLDQsBrbsKGQCqOwsBBrsSKr Rf4KsFoEDvKgDtXAAotwFNUgDuoQs+dwDjFbszNhS7PqgLM3m7M0u7M5y7M9e7NCK7Qyq7NF G7Q+ew7vIA/0YA+UMAB8ABjVAA7iULVWe7VYm7Vau7Vc27Vee7XvYA/IgCAGgAbA4AzQcBxq u7Zs27Zu+7ZwG7dy27aUgCABAQAh+QQFUAD/ACwPAB0AMQALAAAI/wC1CBxIsKDBgwOZDBSD ECGTIAkVPiQI0aHCNWKCaBTzUGOQHTsQBnFVj2GQaLKYmIP3hwmTRvXwBGHXi1u+fPXq6cuH qR6+nfjqTYI3L+e4RnQO7ujlj6GMcftk3PPHTUYQTP7+yNDHrZc7d/7qmWOHdR67r+Y6+YvH zlw9f42UMnUKVUY+ePjGrWjkD8/WcUQE7pMVYgUeuCs07vX3ZoUMMfPMKSy4tKmWp1H1jduh LxpTv5pDauHXaweTP/5Sh11sSOGKePVEE6zMEfNWdiu05EsNmp1of8VCrtEmqzgmGXwNaWzE b57shJj2Sfenj52MffFkMBGzL6sMf/BkCFj0x0z8G3+9fvIjH49p6nprRHYqRr+XS1mdJveK toZJr/wCFdOIQpBFUwwz9GEyTy/MIPjGZA1pQURgEkKoxS6uXFZRhQMFodCEgUEkg3gRljgQ SCamWFBAACH5BAVYAP8ALA0AHQAzAAoAAAj/AP/9W1PMHyY69fz1WiOwoYwgQfA0msiwoUWB fyY2uvhvUqePnSb++6PPn8mT/vL9+deoWDFtIflFYxZPVsNiM4sJZLaPWbRo2ly61DZPm7af 2vS9Obnvnj5890ya23HUlax58zBhMmfzDZ5O8Fy5GsfO3T8xvdx1wjPJqixZkxr9gecOj7ti 7BodlfVmUq9ojcw1YtaLXydMvRqZnPTPqLlO5uK96dWJ6klZWhL6a9rrD7dijfTpE0ikETt9 MsXskIHvXyd/svzBE2M1iCx37P4RcQePnT88YvxxawRvXy9/9zDheePOnTkZ3JALlIUTU7TP WpgIV9yP2Qo8+ri9157HD5+YeP7mMXnT+h8/fv7iRd+HKYSYcfvqvanXvpdPbv+s0MkaWvDD jGbjNEKHP39g4g8TeLhyXHydFcMPN9H4w08vb2Ayjz/msKNNPrCpBSAeJ+GjhQwr+OcSM1qA GA08y5nU0yTuMPFhNP+8IQMzzj220T+9EAVPNHjs0xGGsvTSyy5M/HPiPT4ZYtNKtBni0kjR yNKSOf8wIctRPP6Dxz+Y6IVUPgCOlBY8cMIjy5ksTcLNPnDiw84a/MQT54V9wjPPPfXo4+Uu yNUDZ3eNYNIJYwEBACH5BAlYAP8ALAAAAABQAEgAAAj/AP8JHEiwoMGDCBMqXMiwocOHECNK nEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMK HZpTi9GjRwmO88dU37+kBhsJJEKESS94WPHhm5ePHVKoGr8iZcLkX1lz8OrVY+YOrFEx3O79 axQtWqdiYmTImsdNRhB9g8RuFItUzBsmMnr566RNFjd+TAiP0zJOjBhXsuLVK9ZpnLl65rT1 euo2I+GvO1b8GSf1j7Zifr8yMffnXpBGWmS4uqft3rhecQ2RLo1Ri0CxQZj80RzPHTxDvfSx m2eOrPEg0epp09eJnxZz+f5p/+tU7988TGK0RSZ+0fhwo0wauWMab57AcfnyxevnD96kP0Fg xw4TOzSGBzsraPPGClpow4w547Czg2BhHUcWgbIwVQweK4QAzz9MyRLCP67Mhw8dO+wgA1my rCEcN/i4M0lc9+gFTxAUmnYdHo24wk4n/pgTAo5asMOUP73goeIK9eBjCDPc/NGIGPCs8c8b eNwTTTG9xMOONn+4sx57FhnVCD9HHrkLE9rkc8+RDnaCxx/6pMnUOLJg4t48e7njHDc+5jgY M8w0YqihhpRn36GNFENoI8xEYwijf9STnBZv0BENpvrgs88aRSJF1KiklmrqqaimquqqrLbq 6quwxhYq66y01mrrrbjmquuuvPbq66/AyhoQADs= --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAAACjYSPGctxDJo00lEIk96U13U5HziGIrhZ 3JWSGVY2ESpnirraj0ujIVLr8TQ6TxEmBPpmQ+YJ51ztdMipEhe0ZK9LU8mLXVKLThl4hBaa mVcu8XNOf9nmcbi5ja+nYp62f/dkwsYH1dKF9Hfn9lLlJkXYVgfIqBZpBdn1M7nIR5h3Axlh NPGDWagCqqBRAAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAAAChoQPgZuhDKOclD3onMwo63Z1nuGNEVeJ 5WKaR6nBFNq9H+iqJL0rHF/T2VSPnOUCBO0amxCN18rBkDebLzYVopJQ6fQH/q5Yn2JISCTL xOHKj9mED63ma69anRmPyh59uGXnN3bH1lWIl6gERpdlRXKHocYnUrhkmZKQualHNbeZxyk6 GlEAADs= --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAAACiISPqcvtD6OcMVgLQqa8P41cBnhhZQai o7iSqcl+ytmKJ7bWWrnDfdxIjTZE4TDUO7yIm19TGeQthUamEnd8Dklb6ALHc9CA1ia3GzIz wNJKGUWFThM7L/0XhtSRquxeK2eHJEV2dWPz4oJoQweHNUhYpVPT10cDl7VVqNPm4fnpmAc6 ykHYUAAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACkISPaRHqD+NpErJ7UcNMA7pkyyc6VDdx mYpZJAt7cKuA3DuHd5qq+p4AhWqnm/BxGhWPMtqn1nMCJ7+SxrqxXm3RaCnLGuaq0+erQh6h qU+mK2majSXLMBLnM8Vjxw3+W5aXtoVC2MFlh4TltFdX+OfXJvhT5aVldmZmFPPHE+Qo+NgV IcqptqL2WYiy4nZQAAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACgoyPqcvt74AEalpZZ9AbL55RnZhYyIVu p8aB3ni8Jri+X3TVuYHKnh3b8WamYGrUQ6Z6pBKNKVT6ikaatFkFDq3bJfTKImK7IWPomexS j+dp0p2DUuTgMVL3rm33Hy2fe4cX5iTEpoaVdtYXZQbj2NEI+adlqLe4Q5cpBsHZ6fmZUAAA Ow== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODdhSAAOAIAAAP///wAAACwAAAAASAAOAAACc4yBicbqDyM8UrH2aN08hw5cmvWB5jZW Yumk55u40dqu7GJ7843XfCia/Ho+0k4XGwIvwqaTiDRCPcyo1CoDIpXJau2JUrq8Epo1CcqO S1wcGX2GT6/y7BLzjU/VvxH/PSfXlUfSx4PXhSjoEyQUtAa2VAAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACc4SPqWvhD2NgQB5bpab3de1R4JZEXOks JBJmI8h+0OlOH3226IwrGLOqvSYzj0mUkg2TvqUlNEIyla7ecNfjOIONTXF6zPJwYeF1KqTp zNydM8Mua79EmGqbhKbkbtZxfXflpwSIkoOm9gNkgnjYmFVCUQAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACZYSPqcvtz0Iw8lRwsZyZTg2G3nhVXXJC SKq27gvH8kzXTvmF5rejPPdbBXG6nAUo3HgyHaImtQkWWbaq1RjDWmHKaHH5M0ZzXh9OCVY4 v2XRCLRmD8e+t5yEJcb1c/v2DxgoiFAAADs= --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACH5BAAAAAAALAAAAABIAA4AAAKCBIKJdmqamGN00otzhbF1 HkgdBmniqE0jyp1hisKL+cyeCG9vVtK33zgJLzEbKWSUAW+WIDEZw0Vtq92zhXserZufDhR1 sYzhpBgK7h1rZGuZe4ZT50qvs1a/smnh7fB+N/fyQWfSdzWYxmYBtucB5wLUo/ioArJYKTNj ttTp+UlTAAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhSAAOAIAAAP///wAAACwAAAAASAAOAEACkQSCqcZtwaCb50BE85IR36s5IEh9DXem nai0oVih6vxi9PMk2fmZu66rlG6d1mJiE1pkOOSOiHK5WDAhc2X9WZrBCOyK8xxfTSWvzDQa taOnJ/ykddXTKtnudSdn6zyVN+aUBLYUwzdF8geXOCRGFhQI6dM4pCGzlyehefXmh+RYVrk1 WsJBGHqaSRqHWtrWUAAAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhUABLAPcAAP////f39/L08/Hz8fPy8/Py8u/v7+rt7Ojs6eHs7uvq6ubm5uHk5N7k 4Obe5t7e3tve2dnc29fd2NbW1s/W1M/U0MjY28bTyrbS28zMzMXLxr/Mw8XFxcXJysDFw73D vsW9xbfEvLXFtb2+vZbSr63Csri+u7W8t7y5uLW1vbW1tZy7xaK+rau1ta61rpu8pY3JpqW1 rYrCoKC3vK+wsa2trY+8oZ20pIm7naetqqWtpYLAnIO5l5mwpY22nH7AmaWmpaWlraGmoJGt n4K2mIO0lZ6lop2lnY6vm4iwl320lIKrkpyfoHmrknmrjpmZmZmZmZmZmZmZmXSrioybk4Kg pXmojHOoioyVkYyUjYeSi3Kbg4uMjG2cgIWMiWyaf4KMhHOUhGSefH6IgmuVe4SEhIWHiWWT eHyGgWmOeHqFfWqKdXaCeWONdWCJbnp+fF6IcHZ7e3F7dF+DblOObW14cVyGbHJycmF7bGxz cU2DZF1+amp0bld6ZlR5ZEp6X0d4XVNzYWZmZmZmZmZmZmZmZlFyXl5oYkxyXFRuX09tW1xk YVdhW0trW0toVVVgXExmV1hcW0piUkRfT1NaWUJjSlJaUktXUFFTUUJbS0pRUT1XSUlOTDZc RUJUSD5TRUlJSTdRREFJSD9JRThMQkJCQjROQDVIOztEQStJOjBCOCJJMzY6OyZEMzU4OiJB MS46Mio3LSg7MTMzMyQ8LyE6KRo2KCsvMycyKiQyKCgoKBoxIyMrJyEpIxgpICEjJyAgIBkh HRgfGgwnGRAkGBkZGRQaFhIWEw8PDwkUDgoKCgAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFFADMACwA AAAAUABLAAAI/wABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDQjwA4YDI kwUVVDhR44SGCgpQimSQg0qNERkeIHjQYYFMjwqEjAHiocOEAwGSPsgw4KdGAkDiPPnwoUOD AwKSJp1QIYDTix7eeDmhgkaGDBIOHBigVUCGCF8pGsgxRoUJJjk8TBjxYcEBAwS0KsgQMy7E CjpUZKjBxcgJDxoQ5NCgdkBgrxEyeDXMMMAIHRo8MBlDJYeKDxq45mCA4EABrQEqPODM8IQO CRm85GHzBIgLEx4qNGCSAQECA1m9IshgkjbCDFSAaxG0m4qQlqglUGCyoDVbrREmOP9H6IKK Dh1sIpmRk+WIaRMcKkxwUcG4gddeDVTwOb6gCus6PEEJF3J48YQOLjymwQMsLbAAW5cBwEBX /RHEAYA5HPIGGGpYV8NpGmRQAQUNDEBBB1oBEMAEDFQ40ANUHIHgGItgIQcW7v0GGYkTGDGG HAgkJRACE2xW4QBHHJiDEJRgwQYYTwiR4AcZTHBCGYt4oQICAgj0gHwtugiAC1ic5wIfcXjB RoymfeDCGIfEQQUFfwGAABK4cDFBBEb2p0EWQiCoBSNPsMcEgh+gEckYJ0jAQAEHiFDED6ug csIE/FX4AI465JADI1xsGGUOJggBBgcTPKDABT7sQEIbtAT/A8aCfToXABOH5nCCGnwQGCOC JoTIgAQvKMGDFZ4o44stoLiAqZj/deqCDpFwUYcWvbmgQgURlFAEDDhM0ksuvCgCSDBeWFUr bRVwqisfd6DR4RHbbpAED1s0soUTmaiSCRlt7IJJDhEU1t8BT8iYmIDWYuHSDVbwIIMqvnxB BizCSDLHHp3wgoUGDKzLWQ1KkrpImiqEsIQTOMjgiDKywKFIJob0kYgkiPjCBw0PNNcfdEB4 akIWlDDBQRM88KCEIsEE84kie/gRCCSSkJLJK6gcwaLIcRlwhBA5fHgCJW98kIQSTuwBizGT tNGHIpNM8sknkMCSSi9emNCdiyfI/+hCDR6AgYkKMYjRRRu9GKNIH45Isgkpp2SyBB6yECPI aiFr6neCJ2hihgZbnKHEKcI4QgowkH+yRx9brIHLMLA8cZTPttYAtgsuaPBGJB70IEYTmxzT izCxbKJIGp6Q4QkyivyhBg0cCJD5zzm64CYmT4DuR+LHqLKHG2lsAUkvp3ThwwYAeHBCAAsY UKEBgeKuWByCZDBELscgI8seinxCRizB6AMRWDCBAgBABSMIgAHC1J8PHKEGuNNADh7BhAts QhiICIQd7OAHXpDiCjYIQc+QAgQKBGAA0xtPA3J0ghNkoA6CqAAVWgEHP7ghF7nwgxJekIEG LIABEegAE/9G8AABKIB2znGBb8iSASFcggkUCIUpeHGMTYjBB5eCgAQ4gBMaoEEzBkChiybw wCllgA+LmAAVkkELPUzhBvGZgAdyMIIFBEAFZgiAAO7DgC71JwBmOgF9mCAKLESgEXRAAnw4 kIEcACEDFkjAA7jwAQD8ZQDGcZEGjKAtFUCGEZoYwSY9YALUPAELLVgBBiYAhCcI5C8GWKCL BnC7FlIAC5yIoQfodYI45CELVZgBChjTIgEsYI8I6KOLPiAEGrRQAyM4BCXqcJYTPOEYugDV E1RQAyAIAFLJzACJkEgbBBghB5yjABryEAk+fOABGqiBGZ5wExF5gQELRIAJIsD/AAZkqj8n kBITdXAtShxCEG9gghG4QAOcMOAJKDCOB2jwlwMc00ULOIK2ToCTOlCBCahgBR8ikYUyPOEE qGpkAwzQmwcZQC1iCmiCtuUkF2SBE6LgxBO8wAQaBOcB2kEYDQzwpQYYrD8Z3aj6+ECvHNzh ZGVggmIokCAPZIABDYhAHR9wUb4J9AQVUIMWPmSCHDyBVFYFAg1YpIH21aAC+SQnbTJaA2c2 kg/o1NEHIOMjLjQKUxTIwlG49E+Ago0GJnjhNm3DBCDUIANv0AQX0CKBBXTgDUfppx3FlFGz busIcjiBF+qQAw6oAAgmKANoSukBCRARNxJ4gPvEVCos/wjBAxfIwxEoUYo4cKGsVMqAEWgQ HqYwgAb+dJCY7HQEJrzBBRR4AhsEMQuytQQ+T1ADEDoQngOcAAgGOI4CCLBcEwAhqpDJwxPG ACgmSEkDmMAEFzpQAQmwFAsQWIACWrNcBTzQNLd8w13KIIQRqCAHWFiEETwgygqYlwF7YtFy AeDAHEDPA4I4Ah9EIYgsqGDBpATCCRiQmgPs5YcP4BpnvKbWS2lBDXn4hSsiYQS7eOAJZjDL BI6Sg57oFwET1sATnMkBDFMhD3KgQsK0pYlc0rcBDzCDB/opvQkHAGwmuNRoVXAELqAWCEZY BCewAJkQ+VUCAxBAA1TMmQocIf/LHPjAIqggCE1ElQZUGEENPhC2lXBLAWHc7ITDlmUKeIEP lNAFKijxBG194Alc8AA8MdUdAxTWRRA4qUs8sAg5UCJLSvaUJiIhYL1AgDURAPKEBeKCI9jS C4c4AhbAQCogZMEVqECDCymQqgjMZtUCeeiUOMAINXx6EagdQw6Y4ALIVODZl55w37Isw0uw 4ha34IMXNGqCbnsAMqoG9kAIwOwToOYRIcXEjYzQKRWQxQNNEXdBMsCELGcAC5pgwxi0gIUo deq2bF51DXTgbUYcQg37VnK/KyDvhGS0hRx4wij4gHA2xAEI0W74QO6NIBcsYtGHAEMGNM6Q CrA7oGoGwIJmnBMQACH5BAUUAMwALCQABAAKABIAAAhzAJkJZLZgwsCDzCKUQThQAbARDJkZ OPYrAEMDs5YJYrhARZxlKBAyCAmqlMgazB78qnCQAUpmglS0fIkl5ECXArMYHHgApYInFplR GDFCpocMAu8oW6bsCbMDArksm7pMyMFSVIsxOEjD1a1ILBEe2MowIAAh+QQFFADMACw1AAoA DAASAAAIjgCZCRTIgcbAgwMzUEKIkMGyhQwFRrgDjFNEZh0EBdC1KOKDZVgMGOvAkAGoZRzi mGHYgQkQYG+eMJxQzICQZSNKAtMVAFQNhhlycAFlRibCDAZrFMtxcEEEDj+ZlenILECcYsqA MWVGQBADZneWiV0GRGAALAsWFBura4HACmWZZbnF8cHAEW4FLvgaMSAAIfkECRQAzAAsAAAA AFAASwAACN0AmQkcSLCgwYMIEypcyLChw4cQIwpcMEGixYsYI5TByLEjQwXARngcSVKggWO/ ApRcidHArGWCWMqMuEBFnGUoZupkyCAnqFI7gyJkUIPZg19CkxIkKjCmUqVMmWF5CrUosyxU kx4oquBJ1p0URoxQwcxDhq8z7yhbpszrAbQyuSybu0wI3Jml6BZjcFcmDVe3IlXoO/MAX8KI EytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4 c+vezbu379/Ag1cOCAA7 --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhEAAWAKIGAGV/ov///wAAAGB7nzJAUrbD0////wAAACH5BAEAAAYALAAAAAAQABYA AANTaLrc/jBKIeQiQABLhiiF1AFAEWwKqnTBF5zpxXomrBKBObTCq66Dwo7W+xk6ulbGRspg hhSfg8JywR6CjnVjVGRJUkPXkP0UVOPyeFqxuN9wRgIAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306 Content-Type: image/gif; name="Sent" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Sent" R0lGODlhmgEFAID/AP///zMzmSH/C0FET0JFOklSMS4wAt7tACH5BAAAAAAALAAAAACaAQUA AAJBhI+py+0Po5y02ouz3rz7D4biSJbmiabqygbuC8fyTNf2jef6zvf+DwwKh8Si8YiEsZbM pvMJjUqn1Kr1is1qEQUAOw== --------------050200090204050702040306-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 10:39:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id C485537B413 for ; Wed, 22 Aug 2001 10:39:26 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id BFDD081D18; Wed, 22 Aug 2001 12:39:26 -0500 (CDT) Date: Wed, 22 Aug 2001 12:39:26 -0500 From: Alfred Perlstein To: Anton Berezin Cc: hackers@freebsd.org Subject: Re: VM statistics per process? Message-ID: <20010822123926.P81307@elvis.mu.org> References: <20010822173753.A11906@heechee.tobez.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010822173753.A11906@heechee.tobez.org>; from tobez@tobez.org on Wed, Aug 22, 2001 at 05:37:53PM +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 * Anton Berezin [010822 10:40] wrote: > Hi, > > As a part of a little project studying the perfomance of different > malloc(3) implementations I need to gather certain VM statistics. > > The problem is that the required data are only available globally, and I > need it for a given process. > > Some of the values I am interested in are available from the struct > vmspace, for example > > p->p_vmspace->vm_rssize > > will provide me with the number of resident pages. But I'd like to be > able to also get the number of active and inactive pages belonging to a > particular process. What should I do in order to get this information? getrusage(2) -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 10:48: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 0BDC337B41B for ; Wed, 22 Aug 2001 10:47:48 -0700 (PDT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 63AD9541D; Wed, 22 Aug 2001 19:47:44 +0200 (CEST) Date: Wed, 22 Aug 2001 19:47:44 +0200 From: Anton Berezin To: Alfred Perlstein Cc: hackers@freebsd.org Subject: Re: VM statistics per process? Message-ID: <20010822194744.A14143@heechee.tobez.org> References: <20010822173753.A11906@heechee.tobez.org> <20010822123926.P81307@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010822123926.P81307@elvis.mu.org>; from bright@mu.org on Wed, Aug 22, 2001 at 12:39:26PM -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 Wed, Aug 22, 2001 at 12:39:26PM -0500, Alfred Perlstein wrote: > * Anton Berezin [010822 10:40] wrote: > > The problem is that the required data are only available globally, > > and I need it for a given process. > > > > Some of the values I am interested in are available from the struct > > vmspace, for example > > > > p->p_vmspace->vm_rssize > > > > will provide me with the number of resident pages. But I'd like to > > be able to also get the number of active and inactive pages > > belonging to a particular process. What should I do in order to get > > this information? > getrusage(2) That's not quite it - it does not provide the statistics of what number of pages is currently on PQ_ACTIVE/PQ_INACTIVE queues, and I think I need that number. I was thinking of copying pmap_pid_dump() from sys/i386/i386/pmap.c and counting the pages belonging to different queues. Is this a feasible approach? Cheers, =Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 10:48:41 2001 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 163D337B427 for ; Wed, 22 Aug 2001 10:48:23 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f7MHmCn03461; Wed, 22 Aug 2001 10:48:12 -0700 Date: Wed, 22 Aug 2001 10:48:12 -0700 From: Brooks Davis To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: hackers@freebsd.org Subject: Re: tunable support for ata interrupt sharing Message-ID: <20010822104812.A2840@Odin.AC.HMC.Edu> References: <20010821123726.A15204@Odin.AC.HMC.Edu> <200108211941.f7LJfoP18640@freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108211941.f7LJfoP18640@freebsd.dk>; from sos@freebsd.dk on Tue, Aug 21, 2001 at 09:41:50PM +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 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 21, 2001 at 09:41:50PM +0200, S=F8ren Schmidt wrote: > I have just today committed always sharing all irq's to -current, > the consensus is that if the BIOS allows sharing it should work. > This makes sense, the MB maker is the only one that knows if=20 > this is working, if they blow it in thier BIOS, well.... Cool, I've updated and the new code works. Talk about timeing. ;-) Thanks, 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 --TB36FDmn/VVEgNH/ 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 iD8DBQE7g/BcXY6L6fI4GtQRAn0EAKCgYhva9WftXUW1PNL5p1YbxdxTzwCdGh54 XkIZZriszvfl1BHMcaE+D/E= =OuYL -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 11:24:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 1856737B41F for ; Wed, 22 Aug 2001 11:24:21 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E39E581D07; Wed, 22 Aug 2001 13:24:20 -0500 (CDT) Date: Wed, 22 Aug 2001 13:24:20 -0500 From: Alfred Perlstein To: Anton Berezin Cc: hackers@freebsd.org Subject: Re: VM statistics per process? Message-ID: <20010822132420.Q81307@elvis.mu.org> References: <20010822173753.A11906@heechee.tobez.org> <20010822123926.P81307@elvis.mu.org> <20010822194744.A14143@heechee.tobez.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010822194744.A14143@heechee.tobez.org>; from tobez@tobez.org on Wed, Aug 22, 2001 at 07:47: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 * Anton Berezin [010822 12:47] wrote: > On Wed, Aug 22, 2001 at 12:39:26PM -0500, Alfred Perlstein wrote: > > * Anton Berezin [010822 10:40] wrote: > > > > The problem is that the required data are only available globally, > > > and I need it for a given process. > > > > > > Some of the values I am interested in are available from the struct > > > vmspace, for example > > > > > > p->p_vmspace->vm_rssize > > > > > > will provide me with the number of resident pages. But I'd like to > > > be able to also get the number of active and inactive pages > > > belonging to a particular process. What should I do in order to get > > > this information? > > > getrusage(2) > > That's not quite it - it does not provide the statistics of what number > of pages is currently on PQ_ACTIVE/PQ_INACTIVE queues, and I think I > need that number. Why do you need this? > > I was thinking of copying pmap_pid_dump() from sys/i386/i386/pmap.c and > counting the pages belonging to different queues. Is this a feasible > approach? It may be, I'm not sure how the structures are orginized, it may be an expensive operation to calculate this, but I'm not sure. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 11:43:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from blackcomb.panasas.com (gw2.panasas.com [65.194.124.178]) by hub.freebsd.org (Postfix) with ESMTP id 1447337B418 for ; Wed, 22 Aug 2001 11:43:04 -0700 (PDT) (envelope-from jjacobson@panasas.com) Received: from panasas.com (clouds-rest.panasas.com [172.17.132.184]) by blackcomb.panasas.com (8.9.3/8.9.3) with ESMTP id OAA20972 for ; Wed, 22 Aug 2001 14:43:01 -0400 Message-ID: <3B83FD34.2DA33F67@panasas.com> Date: Wed, 22 Aug 2001 11:43:00 -0700 From: Joel Jacobson X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: vmware under freebsd-4.3 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 i can get vmware to start, but it seems to be having emotional problems getting networking up and running. it gets as far as finding the vmnet device, but ends up sending an unsupported ioctl: linux: 'ioctl' fd=22, cmd=8940 ('\M^I',64) not implemented if i turn networking off, vmware works fine (but is not entirely useful for my purposes). - j To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 11:53: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id DD22E37B408 for ; Wed, 22 Aug 2001 11:52:41 -0700 (PDT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 3E693541D; Wed, 22 Aug 2001 20:52:38 +0200 (CEST) Date: Wed, 22 Aug 2001 20:52:38 +0200 From: Anton Berezin To: Alfred Perlstein Cc: hackers@freebsd.org Subject: Re: VM statistics per process? Message-ID: <20010822205238.A15301@heechee.tobez.org> References: <20010822173753.A11906@heechee.tobez.org> <20010822123926.P81307@elvis.mu.org> <20010822194744.A14143@heechee.tobez.org> <20010822132420.Q81307@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010822132420.Q81307@elvis.mu.org>; from bright@mu.org on Wed, Aug 22, 2001 at 01:24:20PM -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 Wed, Aug 22, 2001 at 01:24:20PM -0500, Alfred Perlstein wrote: > * Anton Berezin [010822 12:47] wrote: > > On Wed, Aug 22, 2001 at 12:39:26PM -0500, Alfred Perlstein wrote: > > > getrusage(2) > > That's not quite it - it does not provide the statistics of what > > number of pages is currently on PQ_ACTIVE/PQ_INACTIVE queues, and I > > think I need that number. > Why do you need this? I am trying to measure the quality of different malloc(3) implementations with regard to the active set size. I need the PQ_ACTIVE number on a theory that, given a light system load and a lots of RAM, a run of a process with a good malloc implementation will have less active pages than the identical run of the same process with a bad malloc implementation. Consequently, such `good' (by this criterion) malloc(3) will be also good, or even better, in case of a heavy system load. I know that phkmalloc is supposed to be good in this regard, but I am trying to see whether there are better ones, especially for specific programs that are known to be rather harsh memory users (perl). > > I was thinking of copying pmap_pid_dump() from sys/i386/i386/pmap.c > > and counting the pages belonging to different queues. Is this a > > feasible approach? > It may be, I'm not sure how the structures are orginized, it may be an > expensive operation to calculate this, but I'm not sure. I am sure it is not an expensive operation to *calculate*, since pmap_pid_dump() deals with vm_page_t structures which have a queue field - just what I need. What I worry about is that the actual *traversal* might be expensive. Worse, pmap_pid_dump() is undocumented, and I don't understand what for(i=0;i<1024;i++) for(j=0;j<1024;j++) {} loop there is supposed to do... :-( I'd appreciate if someone would explain this to me. =Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 12:47:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from herbelot.dyndns.org (d211.dhcp212-26.cybercable.fr [212.198.26.211]) by hub.freebsd.org (Postfix) with ESMTP id 3B90437B428 for ; Wed, 22 Aug 2001 12:47:51 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id WAA70451 for ; Wed, 22 Aug 2001 22:01:27 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B840C56.BDB7424D@herbelot.com> Date: Wed, 22 Aug 2001 21:47:34 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: clock synchronization quality via NTP ? 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, I know FreeBSD can be used with great success for timing solutions (at least two core members do it ?). has someone some performance data of the quality of system clock synchronization, while using NTPd with a GPS reveiver and a hard 1PPS signal ? More precisely : is it reasonable to hope having a system clock not farther from the GPS clock by more than 50 micro-seconds ? -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 13:10:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.teledis.be (mail.teledis.be [217.117.32.52]) by hub.freebsd.org (Postfix) with ESMTP id A14FD37B40A for ; Wed, 22 Aug 2001 13:10:12 -0700 (PDT) (envelope-from lorenzo@linuxbe.org) Received: from natalie ([217.117.38.8]) by mail.teledis.be (Netscape Messaging Server 4.15) with SMTP id GIHK0P00.DBY for ; Wed, 22 Aug 2001 22:10:01 +0200 Message-ID: <005a01c12b46$e38c1c80$0201a8c0@teledisnet.be> From: "Sansonetti Laurent" To: Subject: struct module Date: Wed, 22 Aug 2001 22:13:20 +0200 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 hackers, First of all thank to all people who help me, my KLD module is almost finished. I have however a small question : why the module structure is definied in /sys/kern/kern_module.c and not in ? I'm sure this question has a stupid answer.. ;-) Bye, and thanks in advance for your answer. -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 13:17:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from slc.robotech.net (www.cyber-wire.com [209.119.76.3]) by hub.freebsd.org (Postfix) with ESMTP id 2A20D37B448 for ; Wed, 22 Aug 2001 13:17:32 -0700 (PDT) (envelope-from johnson@faradayco.com) Received: from faradayco.com [216.4.209.14] by slc.robotech.net with ESMTP (SMTPD32-5.05) id A2C78EA70226; Wed, 22 Aug 2001 14:15:03 -0600 Message-ID: <3B84149C.8DD7F30B@faradayco.com> Date: Wed, 22 Aug 2001 14:22:52 -0600 From: djohnson X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: pci_get_devid() 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 I'm doing some PCI related code and keep running into the function/method pci_get_devid() in FreeBSD source files (like pcisupport.c). A couple of us have looked for this function in our systems and can't seem to find it. Can anyone tell me where I can find the source for pci_get_devid()? By the way, I'm trying to write a little application that gives a detailed enumeration of the PCI bus using BIOS calls. Thanks in advance. D. Johnson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 13:28:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f61.pav2.hotmail.com [64.4.37.61]) by hub.freebsd.org (Postfix) with ESMTP id 5E42837B420 for ; Wed, 22 Aug 2001 13:28:42 -0700 (PDT) (envelope-from weiguang_shi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Aug 2001 13:28:42 -0700 Received: from 129.128.4.151 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 22 Aug 2001 20:28:42 GMT X-Originating-IP: [129.128.4.151] From: "Weiguang SHI" To: johnson@faradayco.com, freebsd-hackers@FreeBSD.org Subject: Re: pci_get_devid() Date: Wed, 22 Aug 2001 14:28:42 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Aug 2001 20:28:42.0254 (UTC) FILETIME=[08C0BAE0:01C12B49] 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 Take a look at PCI_ACCESSOR in "pcivar.h" Good Luck Weiguang >From: djohnson >To: freebsd-hackers@FreeBSD.org >Subject: pci_get_devid() >Date: Wed, 22 Aug 2001 14:22:52 -0600 > >I'm doing some PCI related code and keep running into the >function/method pci_get_devid() in FreeBSD source files (like >pcisupport.c). A couple of us have looked for this function in our >systems and can't seem to find it. Can anyone tell me where I can find >the source for pci_get_devid()? By the way, I'm trying to write a >little application that gives a detailed enumeration of the PCI bus >using BIOS calls. Thanks in advance. > >D. Johnson > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 13:50:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by hub.freebsd.org (Postfix) with ESMTP id 214B137B42C for ; Wed, 22 Aug 2001 13:50:27 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA00509; Wed, 22 Aug 2001 22:50:25 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.4/8.11.4) id f7MKoPV33159; Wed, 22 Aug 2001 22:50:25 +0200 (CEST) (envelope-from wkb) Date: Wed, 22 Aug 2001 22:50:25 +0200 From: Wilko Bulte To: Thierry Herbelot Cc: hackers@FreeBSD.ORG Subject: Re: clock synchronization quality via NTP ? Message-ID: <20010822225025.A33131@freebie.xs4all.nl> References: <3B840C56.BDB7424D@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B840C56.BDB7424D@herbelot.com>; from thierry@herbelot.com on Wed, Aug 22, 2001 at 09:47:34PM +0200 X-OS: FreeBSD 4.3-STABLE 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, Aug 22, 2001 at 09:47:34PM +0200, Thierry Herbelot wrote: > Hello, > > I know FreeBSD can be used with great success for timing solutions (at > least two core members do it ?). > > has someone some performance data of the quality of system clock > synchronization, while using NTPd with a GPS reveiver and a hard 1PPS > signal ? > > More precisely : is it reasonable to hope having a system clock not > farther from the GPS clock by more than 50 micro-seconds ? Talk to Poul-Henning, he is the clock/time expert (phk@FreeBSD.org). Poul used to have some nice Web pages around on this subject but they were killed in a disk crash IIRC. -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 13:55:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from slc.robotech.net (www.cyber-wire.com [209.119.76.3]) by hub.freebsd.org (Postfix) with ESMTP id 3CC6537B444 for ; Wed, 22 Aug 2001 13:55:13 -0700 (PDT) (envelope-from johnson@faradayco.com) Received: from faradayco.com [216.4.209.14] by slc.robotech.net with ESMTP (SMTPD32-5.05) id AB9B68C60266; Wed, 22 Aug 2001 14:52:43 -0600 Message-ID: <3B841D70.71007AA5@faradayco.com> Date: Wed, 22 Aug 2001 15:00:32 -0600 From: djohnson X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: pci_get_devid() 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 A list member refered me to PCI_ACCESSOR in pcivar.h for the solution. Thanks W.S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 13:56:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 52C0A37B42B; Wed, 22 Aug 2001 13:55:14 -0700 (PDT) Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: <200108210623.f7L6NdY90348@aslan.scsiguy.com> from "Justin T. Gibbs" at "Aug 21, 2001 00:23:39 am" To: gibbs@scsiguy.com (Justin T. Gibbs) Date: Wed, 22 Aug 2001 13:55:14 -0700 (PDT) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010822205514.52C0A37B42B@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) 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 understanding is that you need a dmamap for every buffer that you want > >to map into bus space. > > You need one dmamap for each independantly manageable mapping. A > single mapping may result in a long list of segments, regardless > of whether you have a single KVA buffer or multiple KVA buffers > that might contribute to the mapping. Yes yes, I understand that. But that's only if you want to map a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K buffer being sent to a disk controller. What I want to make sure everyone understands here is that I'm not typically dealing with buffers this large: instead I have lots of small buffers that are smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 bytes, of which only a fraction is used for data. An mbuf cluster buffer is usually only 2048 bytes. Transmitted packets are typically fragmented across 2 or 3 mbufs: the first mbuf contains the header, and the other two contain data. (Or the first one contains part of the header, the second one contains additional header data, and the third contains data -- whatever.) At most I will have 1500 bytes of data to send, which is less than PAGE_SIZE, and that 1500 bytes will be fragmented across a bunch of smaller buffers that are also smaller than PAGE_SIZE. Therefore I will not have one dmamap with multiple segments: I will have a bunch of dmamaps with one segment each. (I can hear somebody out there saying: "What about jumbo frames?" Yes, with jumbo frames, I will have 9K buffers to deal with, and in that case, you could have one dmamap with several segments, and I am taking this into account with the updated code I've written.) > >So unless I'm mistaken, for each mbuf in an mbuf list, what we > >have to do is this: > > > >- create a bus_dmamap_t for the data area in the mbuf using > > bus_dmamap_create() > > Creating a dmamap, depending on the architecture, could be expensive. > You really want to create them in advance (or pool them), with at most > one dmamap per concurrent transaction you support in your driver. The only problem here is that I can't really predict how many transactions will be going at one time. I will have at least RX_DMA_RING maps (one for each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. I could have the TX DMA ring completely filled with packets waiting to be DMA'ed and transmitted, or I may have only one entry in the ring currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING dmamaps in order to be safe. > >- do the physical to bus mapping with bus_dmamap_load() > > bus_dmamap_load() only understands how to map a single buffer. > You will have to pull pieces of bus_dmamap_load into a new > function (or create inlines for common bits) to do this > correctly. The algorithm goes something like this: > > foreach mbuf in the mbuf chain to load > /* > * Parse this contiguous piece of KVA into > * its bus space regions. > */ > foreach "bus space" discontiguous region > if (too_many_segs) > return (error); > Add new S/G element > > With the added complications of deferring the mapping if we're > out of space, issuing the callback, etc. Why can't I just call bus_dmamap_load() multiple times, once for each mbuf in the mbuf list? (Note: for the record, an mbuf list usually contains one packet fragmented across multiple mbufs. An mbuf chain contains several mbuf lists, linked together via the m_nextpkt pointer in the header of the first mbuf in each list. By the time we get to the device driver, we always have mbuf lists only.) > Chances are you are going to use the map again soon, so destroying > it on every transaction is a waste. Ok, I spent some more time on this. I updated the code at: http://www.freebsd.org/~wpaul/busdma The changes are: - Tried to account for the case where an mbuf data region is larger than a page, i.e. when we have an mbuf with a 9K external buffer attached for use a jumbo ethernet frame. - Added routines to allocate a chunk of maps in a singly linked list, from which the other routines can grab them as needed. The driver attach routine calls bus_dmamap_list_init() with the max number of dmamaps that it will need, then the detach routine calls bus_dmamap_list_destroy() to nuke them when the driver is unloaded. The bus_dmamap_load_mbuf() routine uses the pre-allocated dmamaps from the list and bus_dmamap_list_destroy() returns them to the list when the transaction is completed. - Updated the modified if_sf driver to use the new code. Again, I've got this code running on the test box in the lab, so it's correct inasmuch as it compiles and runs, even though it may not be aesthetically pleasing. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 14:16:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id A130137B438; Wed, 22 Aug 2001 14:15:45 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id f7MLFiY16846; Wed, 22 Aug 2001 15:15:44 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200108222115.f7MLFiY16846@aslan.scsiguy.com> To: wpaul@FreeBSD.ORG (Bill Paul) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: Your message of "Wed, 22 Aug 2001 13:55:14 PDT." <20010822205514.52C0A37B42B@hub.freebsd.org> Date: Wed, 22 Aug 2001 15:15:44 -0600 From: "Justin T. Gibbs" 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 understanding is that you need a dmamap for every buffer that you want >> >to map into bus space. >> >> You need one dmamap for each independantly manageable mapping. A >> single mapping may result in a long list of segments, regardless >> of whether you have a single KVA buffer or multiple KVA buffers >> that might contribute to the mapping. > >Yes yes, I understand that. But that's only if you want to map >a buffer that's larger than PAGE_SIZE bytes, like, say, a 64K >buffer being sent to a disk controller. What I want to make sure >everyone understands here is that I'm not typically dealing with >buffers this large: instead I have lots of small buffers that are >smaller than PAGE_SIZE bytes. A single mbuf alone is only 256 >bytes, of which only a fraction is used for data. An mbuf cluster >buffer is usually only 2048 bytes. Transmitted packets are typically >fragmented across 2 or 3 mbufs: the first mbuf contains the header, >and the other two contain data. (Or the first one contains part >of the header, the second one contains additional header data, >and the third contains data -- whatever.) At most I will have 1500 >bytes of data to send, which is less than PAGE_SIZE, and that 1500 >bytes will be fragmented across a bunch of smaller buffers that >are also smaller than PAGE_SIZE. Therefore I will not have one >dmamap with multiple segments: I will have a bunch of dmamaps >with one segment each. The fact that the data is less than a page in size matters little to the bus dma concept. In other words, how is this packet presented to the hardware? Does it care that all of the component pieces are < PAGE_SIZE in length? Probably not. It just wants the list of address/length pairs that compose that packet and there is no reason that each chunk needs to have it own, and potentially expensive, dmamap. >> Creating a dmamap, depending on the architecture, could be expensive. >> You really want to create them in advance (or pool them), with at most >> one dmamap per concurrent transaction you support in your driver. > >The only problem here is that I can't really predict how many transactions >will be going at one time. I will have at least RX_DMA_RING maps (one for >each mbuf in the RX DMA ring), and some fraction of TX_DMA_RING maps. >I could have the TX DMA ring completely filled with packets waiting >to be DMA'ed and transmitted, or I may have only one entry in the ring >currently in use. So I guess I have to allocate RX_DMA_RING + TX_DMA_RING >dmamaps in order to be safe. Yes or allocate them in chunks so that the total amount is only as large as the greatest demand your driver has ever seen. >> With the added complications of deferring the mapping if we're >> out of space, issuing the callback, etc. > >Why can't I just call bus_dmamap_load() multiple times, once for >each mbuf in the mbuf list? Due to the cost of the dmamaps, the cost of which is platform and bus-dma implementation dependent - e.g. could be a 1-1 mapping to a hardware resource. Consider the case of having a full TX and RX ring in your driver. Instead of #TX*#RX dmamaps, you will now have three or more times that number. There is also the issue of coalessing the discontiguous chunks if there are too many chunks for your driver to handle. Bus dma is supposed to handle that for you (the x86 implementation doesn't yet, but it should) but it can't if it doesn't understand the segment limit per transaction. You've hidden that from bus dma by using a map per segment. >(Note: for the record, an mbuf list usually contains one packet >fragmented across multiple mbufs. An mbuf chain contains several >mbuf lists, linked together via the m_nextpkt pointer in the >header of the first mbuf in each list. By the time we get to >the device driver, we always have mbuf lists only.) Okay, so I haven't written a network driver yet, but you got the idea, right? 8-) >> Chances are you are going to use the map again soon, so destroying >> it on every transaction is a waste. > >Ok, I spent some more time on this. I updated the code at: > >http://www.freebsd.org/~wpaul/busdma I'll take a look. >The changes are: ... >- Added routines to allocate a chunk of maps in a singly linked list, > from which the other routines can grab them as needed. Are these hung off the dma tag or something? dmamaps may hold settings that are peculuar to the device that allocated them, so they cannot be shared with other clients of bus_dmamap_load_mbuf. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 14:54:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 3090537B40B; Wed, 22 Aug 2001 14:53:51 -0700 (PDT) Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: <200108222115.f7MLFiY16846@aslan.scsiguy.com> from "Justin T. Gibbs" at "Aug 22, 2001 03:15:44 pm" To: gibbs@scsiguy.com (Justin T. Gibbs) Date: Wed, 22 Aug 2001 14:53:51 -0700 (PDT) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010822215351.3090537B40B@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) 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 fact that the data is less than a page in size matters little > to the bus dma concept. In other words, how is this packet presented > to the hardware? Does it care that all of the component pieces are > < PAGE_SIZE in length? Probably not. It just wants the list of > address/length pairs that compose that packet and there is no reason > that each chunk needs to have it own, and potentially expensive, dmamap. Maybe, but bus_dmamap_load() only lets you map one buffer at a time. I want to map a bunch of little buffers, and the API doesn't let me do that. And I don't want to change the API, because that would mean modifying busdma_machdep.c on each platform, which is a hell that I would rather avoid. > >Why can't I just call bus_dmamap_load() multiple times, once for > >each mbuf in the mbuf list? > > Due to the cost of the dmamaps, the cost of which is platform and > bus-dma implementation dependent - e.g. could be a 1-1 mapping to > a hardware resource. Consider the case of having a full TX and RX > ring in your driver. Instead of #TX*#RX dmamaps, you will now have > three or more times that number. > > There is also the issue of coalessing the discontiguous chunks if > there are too many chunks for your driver to handle. Bus dma is > supposed to handle that for you (the x86 implementation doesn't > yet, but it should) but it can't if it doesn't understand the segment > limit per transaction. You've hidden that from bus dma by using a > map per segment. Ok, a slightly different question: what happens if I call bus_dmamap_load() more than once with different buffers but with the same dmamap? > >(Note: for the record, an mbuf list usually contains one packet > >fragmented across multiple mbufs. An mbuf chain contains several > >mbuf lists, linked together via the m_nextpkt pointer in the > >header of the first mbuf in each list. By the time we get to > >the device driver, we always have mbuf lists only.) > > Okay, so I haven't written a network driver yet, but you got the idea, > right? 8-) Just don't get 3c509 and 3c905 misxed up and we'll be fine. :) > >- Added routines to allocate a chunk of maps in a singly linked list, > > from which the other routines can grab them as needed. > > Are these hung off the dma tag or something? dmamaps may hold settings > that are peculuar to the device that allocated them, so they cannot > be shared with other clients of bus_dmamap_load_mbuf. It's a separate list. The driver is reponsible for allocating the head of the list, then it hands it to bus_dmamap_list_alloc() along with the required dma tag. bus_dmamap_list_alloc() then calls bus_dmapap_create() to populate the list. The driver doesn't have to manipulate the list itself, until time comes to destroy it. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 15:17:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id C467537B420; Wed, 22 Aug 2001 15:17:08 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id f7MMH7Y18044; Wed, 22 Aug 2001 16:17:07 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200108222217.f7MMH7Y18044@aslan.scsiguy.com> To: wpaul@FreeBSD.ORG (Bill Paul) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: Your message of "Wed, 22 Aug 2001 14:53:51 PDT." <20010822215351.3090537B40B@hub.freebsd.org> Date: Wed, 22 Aug 2001 16:17:07 -0600 From: "Justin T. Gibbs" 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 fact that the data is less than a page in size matters little >> to the bus dma concept. In other words, how is this packet presented >> to the hardware? Does it care that all of the component pieces are >> < PAGE_SIZE in length? Probably not. It just wants the list of >> address/length pairs that compose that packet and there is no reason >> that each chunk needs to have it own, and potentially expensive, dmamap. > >Maybe, but bus_dmamap_load() only lets you map one buffer at a time. >I want to map a bunch of little buffers, and the API doesn't let me >do that. And I don't want to change the API, because that would mean >modifying busdma_machdep.c on each platform, which is a hell that I >would rather avoid. bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf or bus_dmamap_load_uio or also part of the API. They just don't happen to be impmeneted yet. 8-) Perhaps there should be an MD primitive that knows how to append to a mapping? This would allow you to write an MI loop that does exactly what you want. >> there are too many chunks for your driver to handle. Bus dma is >> supposed to handle that for you (the x86 implementation doesn't >> yet, but it should) but it can't if it doesn't understand the segment >> limit per transaction. You've hidden that from bus dma by using a >> map per segment. > >Ok, a slightly different question: what happens if I call >bus_dmamap_load() more than once with different buffers but with >the same dmamap? The behavior is undefined. >> >- Added routines to allocate a chunk of maps in a singly linked list, >> > from which the other routines can grab them as needed. >> >> Are these hung off the dma tag or something? dmamaps may hold settings >> that are peculuar to the device that allocated them, so they cannot >> be shared with other clients of bus_dmamap_load_mbuf. > >It's a separate list. The driver is reponsible for allocating the >head of the list, then it hands it to bus_dmamap_list_alloc() along >with the required dma tag. bus_dmamap_list_alloc() then calls >bus_dmapap_create() to populate the list. The driver doesn't have >to manipulate the list itself, until time comes to destroy it. Okay, but does this mean that bus_dmamap_load_mbuf no longer takes a dmamap? Drivers may want to allocate/manage the dmamaps in a different way. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 15:45: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from naboo.ethz.ch (naboo.ethz.ch [129.132.17.66]) by hub.freebsd.org (Postfix) with ESMTP id D71C337B44B for ; Wed, 22 Aug 2001 15:44:46 -0700 (PDT) (envelope-from carlo@vis.ethz.ch) Received: by naboo.ethz.ch (Postfix, from userid 224) id E1585275B7; Thu, 23 Aug 2001 00:44:45 +0200 (CEST) Subject: ports/lang/gcc{-devel,30} To: freebsd-hackers@freebsd.org Date: Thu, 23 Aug 2001 00:44:45 +0200 (CEST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010822224445.E1585275B7@naboo.ethz.ch> From: carlo@vis.ethz.ch (Carlo Dapor) 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 Dear hackers Can somebody shed a light on the two ports ? At first sight, they seem very similar. Are there plans to update them ? They both are based on a snapshot dated April 30th, 2001. Any hints are appreciated. Ciao, derweil, -- Carlo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 15:52:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 0EB8637B43C; Wed, 22 Aug 2001 15:52:19 -0700 (PDT) Subject: Re: Where to put new bus_dmamap_load_mbuf() code In-Reply-To: <200108222217.f7MMH7Y18044@aslan.scsiguy.com> from "Justin T. Gibbs" at "Aug 22, 2001 04:17:07 pm" To: gibbs@scsiguy.com (Justin T. Gibbs) Date: Wed, 22 Aug 2001 15:52:18 -0700 (PDT) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010822225219.0EB8637B43C@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) 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 > >Maybe, but bus_dmamap_load() only lets you map one buffer at a time. > >I want to map a bunch of little buffers, and the API doesn't let me > >do that. And I don't want to change the API, because that would mean > >modifying busdma_machdep.c on each platform, which is a hell that I > >would rather avoid. > > bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf > or bus_dmamap_load_uio or also part of the API. They just don't happen > to be impmeneted yet. 8-) Perhaps there should be an MD primitive > that knows how to append to a mapping? This would allow you to write > an MI loop that does exactly what you want. Any one of those ideas would be just fine. I eagerly await their realization. :) > >It's a separate list. The driver is reponsible for allocating the > >head of the list, then it hands it to bus_dmamap_list_alloc() along > >with the required dma tag. bus_dmamap_list_alloc() then calls > >bus_dmapap_create() to populate the list. The driver doesn't have > >to manipulate the list itself, until time comes to destroy it. > > Okay, but does this mean that bus_dmamap_load_mbuf no longer takes > a dmamap? Drivers may want to allocate/manage the dmamaps in a > different way. Yes, bus_dmamap_load_mbuf() accepts a dma tag, the head of the dmamap list, an mbuf, an segment array and a segment count. The Driver allocates the segment array with a certain number of members. It passes the array and segment count to bus_dmamap_load_mbuf(), which treats the segment count as the maximum number of segments that it can return to the caller. Once all the mappings have been done, it updates the segment count to indicate how many segments were actually needed. Then the driver transfers the info from the segment array into its DMA descriptor structures and kicks off the DMA operation. Once the device signals the transfer is done, the driver calls bus_dmamap_unload_mbuf() and bus_dmamap_destroy_mbuf() to unload the maps and return them to the map list for later use. It isn't until the driver calls bus_dmamap_list_destroy() that the dmamaps are actually released and the list free()ed. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 15:58:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-7.dsl.lsan03.pacbell.net [63.207.60.7]) by hub.freebsd.org (Postfix) with ESMTP id 9FE7737B409; Wed, 22 Aug 2001 15:57:49 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3906666D1C; Wed, 22 Aug 2001 15:57:49 -0700 (PDT) Date: Wed, 22 Aug 2001 15:57:49 -0700 From: Kris Kennaway To: David O'Brien Cc: Kris Kennaway , hackers@FreeBSD.org Subject: Re: [PATCH] install -s -s(trip-me-harder) Message-ID: <20010822155748.B35838@xor.obsecurity.org> References: <20010820001654.A32129@xor.obsecurity.org> <20010822004250.A65425@dragon.nuxi.com> <20010822014007.A27686@xor.obsecurity.org> <20010822092644.C48284@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010822092644.C48284@dragon.nuxi.com>; from obrien@FreeBSD.org on Wed, Aug 22, 2001 at 09:26:44AM -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 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2001 at 09:26:44AM -0700, David O'Brien wrote: > On Wed, Aug 22, 2001 at 01:40:07AM -0700, Kris Kennaway wrote: > > > Getting rid of .note[.ABI-tag] will interfere with ELF branding. > >=20 > > How will it do so? >=20 > This is the ELF ABI standard-approved way of doing ELF branding: >=20 > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk I= nf Al > [ 2] .note.ABI-tag NOTE 08048110 000110 000018 00 A 0 0= 4 >=20 > with the source of this (for FreeBSD native binaries) being > src/lib/csu/common/crtbrand.c. >=20 > See http://www.netbsd.org/Documentation/kernel/elf-notes.html for more > information. Thanks, but my patch doesn't seem to touch .note.ABI-tag, only .note Kris --OgqxwSJOaUobr8KG 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 iD8DBQE7hDjsWry0BWjoQKURAlMuAJ4/5vt0XtiG5aUvbGbi1qc2utHhdgCfSzrt 00eYpw0HidvNs9ZXRBJT634= =KtdE -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 16:28:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2]) by hub.freebsd.org (Postfix) with ESMTP id DC96D37B5AF for ; Wed, 22 Aug 2001 16:27:53 -0700 (PDT) (envelope-from mreimer@vpop.net) Received: from vpop.net (bilbo.vpop.net [63.231.252.113]) by boromir.vpop.net (8.11.4/8.11.4) with ESMTP id f7MNRni08079 for ; Wed, 22 Aug 2001 16:27:50 -0700 (PDT) (envelope-from mreimer@vpop.net) Message-ID: <3B843FF7.F9B04318@vpop.net> Date: Wed, 22 Aug 2001 18:27:51 -0500 From: Matthew Reimer Organization: VPOP Technologies, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Firewire driver available 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 I saw this on Freshmeat the other day: http://www.sfc.wide.ad.jp/DVTS/ Maybe someday it can be committed? Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 16:30:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A535837B412 for ; Wed, 22 Aug 2001 16:30:30 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7MNUUj80882; Wed, 22 Aug 2001 16:30:30 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 16:30:30 -0700 (PDT) From: Matt Dillon Message-Id: <200108222330.f7MNUUj80882@earth.backplane.com> To: freebsd-hackers@freebsd.org Subject: ssh password cracker - now this *is* cool! 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 gets an 'A' on my cool-o-meter. http://www.vnunet.com/News/1124839 -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 16:38:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 74AD937B41E for ; Wed, 22 Aug 2001 16:38:07 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5F97681D07; Wed, 22 Aug 2001 18:38:07 -0500 (CDT) Date: Wed, 22 Aug 2001 18:38:07 -0500 From: Alfred Perlstein To: Matt Dillon Cc: freebsd-hackers@freebsd.org Subject: Re: ssh password cracker - now this *is* cool! Message-ID: <20010822183807.T81307@elvis.mu.org> References: <200108222330.f7MNUUj80882@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108222330.f7MNUUj80882@earth.backplane.com>; from dillon@earth.backplane.com on Wed, Aug 22, 2001 at 04:30:30PM -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 * Matt Dillon [010822 18:30] wrote: > This gets an 'A' on my cool-o-meter. > > http://www.vnunet.com/News/1124839 Interesting, I guess one could work around it by periodically sending bogus empty packets in the middle of activity. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 16:47:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7821737B40E for ; Wed, 22 Aug 2001 16:47:16 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7MNlF781161; Wed, 22 Aug 2001 16:47:15 -0700 (PDT) (envelope-from dillon) Date: Wed, 22 Aug 2001 16:47:15 -0700 (PDT) From: Matt Dillon Message-Id: <200108222347.f7MNlF781161@earth.backplane.com> To: Alfred Perlstein Cc: freebsd-hackers@freebsd.org Subject: Re: ssh password cracker - now this *is* cool! References: <200108222330.f7MNUUj80882@earth.backplane.com> <20010822183807.T81307@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 : :* Matt Dillon [010822 18:30] wrote: :> This gets an 'A' on my cool-o-meter. :> :> http://www.vnunet.com/News/1124839 : :Interesting, I guess one could work around it by periodically :sending bogus empty packets in the middle of activity. : :-- :-Alfred Perlstein [alfred@freebsd.org] Yah, and typing backspaces also ought to work. 12345bb45bb45678b8 -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 16:53:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.netcom.com (freebsd.netcom.com [199.174.33.250]) by hub.freebsd.org (Postfix) with ESMTP id 8947837B509 for ; Wed, 22 Aug 2001 16:53:20 -0700 (PDT) (envelope-from bugs@freebsd.netcom.com) Received: (from bugs@localhost) by freebsd.netcom.com (8.8.8+Sun/8.8.8) id SAA14636 for hackers@freebsd.org; Wed, 22 Aug 2001 18:52:19 -0500 (CDT) From: Mark Hittinger Message-Id: <200108222352.SAA14636@freebsd.netcom.com> Subject: Re: ssh password cracker - now this *is* cool! To: hackers@freebsd.org Date: Wed, 22 Aug 2001 18:52:19 -0500 (CDT) X-Mailer: ELM [version 2.5 PL2] 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 > > Yah, and typing backspaces also ought to work. 12345bb45bb45678b8 > How about some control-Q's? :-) Later Mark Hittinger Earthlink bugs@freebsd.netcom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 16:55:24 2001 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 61BC137B40F for ; Wed, 22 Aug 2001 16:55:09 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f7MNt8594941 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Aug 2001 19:55:08 -0400 (EDT) (envelope-from bicknell) Date: Wed, 22 Aug 2001 19:55:08 -0400 From: Leo Bicknell To: freebsd-hackers@FreeBSD.ORG Subject: Re: ssh password cracker - now this *is* cool! Message-ID: <20010822195508.B93930@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , freebsd-hackers@FreeBSD.ORG References: <200108222330.f7MNUUj80882@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108222330.f7MNUUj80882@earth.backplane.com>; from dillon@earth.backplane.com on Wed, Aug 22, 2001 at 04:30:30PM -0700 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 On Wed, Aug 22, 2001 at 04:30:30PM -0700, Matt Dillon wrote: > http://www.vnunet.com/News/1124839 Several people on other mailing lists have pointed out that Nagle should make this much harder, although it's unclear how Nagle and ssh interact. So far that has resulted in a number of degenerating discussions of how things work. Of course, Nagle will not help between two machines on the same ethernet segment, but probably would make the process described in the paper much harder. All of this aruges for Kerberos or some other cryptographic system so once you're authenticated once there is little or no need to type additional passwords. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 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 Wed Aug 22 17:11: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail25.sdc1.sfba.home.com (femail25.sdc1.sfba.home.com [24.254.60.15]) by hub.freebsd.org (Postfix) with ESMTP id 4518337B406 for ; Wed, 22 Aug 2001 17:10:20 -0700 (PDT) (envelope-from bmah@employees.org) Received: from intruder.bmah.org ([24.176.204.87]) by femail25.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010823001017.JZXU21066.femail25.sdc1.sfba.home.com@intruder.bmah.org>; Wed, 22 Aug 2001 17:10:17 -0700 Received: (from bmah@localhost) by intruder.bmah.org (8.11.5/8.11.3) id f7N0AGf27563; Wed, 22 Aug 2001 17:10:16 -0700 (PDT) (envelope-from bmah) Message-Id: <200108230010.f7N0AGf27563@intruder.bmah.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Leo Bicknell Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ssh password cracker - now this *is* cool! In-Reply-To: <20010822195508.B93930@ussenterprise.ufp.org> References: <200108222330.f7MNUUj80882@earth.backplane.com> <20010822195508.B93930@ussenterprise.ufp.org> Comments: In-reply-to Leo Bicknell message dated "Wed, 22 Aug 2001 19:55:08 -0400." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-784623144P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 22 Aug 2001 17:10:16 -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 --==_Exmh_-784623144P Content-Type: text/plain; charset=us-ascii If memory serves me right, Leo Bicknell wrote: > On Wed, Aug 22, 2001 at 04:30:30PM -0700, Matt Dillon wrote: > > http://www.vnunet.com/News/1124839 > > Several people on other mailing lists have pointed out that Nagle > should make this much harder, although it's unclear how Nagle and > ssh interact. So far that has resulted in a number of degenerating > discussions of how things work. Of course, Nagle will not help > between two machines on the same ethernet segment, but probably > would make the process described in the paper much harder. Indeed. They also didn't discuss (or I didn't see it) the effects of queueing or jitter in the network on their scheme. This *is* pretty neat, although it is less of a password cracker than a scheme of narrowing down the space of possible passwords. > All of this aruges for Kerberos or some other cryptographic system > so once you're authenticated once there is little or no need to type > additional passwords. ssh-agent(1)/ssh-add(1) does all of its authentication locally, so my extremely naive reading is that it'd be immune to this particular type of attack, since human-typed passphrases never cross the network. Bruce. --==_Exmh_-784623144P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE7hEno2MoxcVugUsMRArNrAJ48wC3f2ohuJPyRsGXgRbPeujFBOwCfaMiQ IGRJRrAlgZcd5LzeTI8mm7E= =mGrn -----END PGP SIGNATURE----- --==_Exmh_-784623144P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 17:45:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 7832B37B420 for ; Wed, 22 Aug 2001 17:45:17 -0700 (PDT) (envelope-from gjb@gbch.net) Received: (qmail 28419 invoked by uid 1001); 23 Aug 2001 10:45:07 +1000 Message-ID: X-Posted-By: GJB-Post 2.21 16-Jun-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Thu, 23 Aug 2001 10:45:07 +1000 From: Greg Black To: Matt Dillon Cc: freebsd-hackers@freebsd.org Subject: Re: ssh password cracker - now this *is* cool! References: <200108222330.f7MNUUj80882@earth.backplane.com> In-reply-to: <200108222330.f7MNUUj80882@earth.backplane.com> of Wed, 22 Aug 2001 16:30:30 MST 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 Matt Dillon wrote: | This gets an 'A' on my cool-o-meter. | | http://www.vnunet.com/News/1124839 The real research might be interesting, but the information in the article seems to be wrong. It says: Each keystroke from a user is immediately sent to the target machine as a separate IP packet. By performing a statistical study on a user's typing patterns, and applying a key sequence prediction algorithm, the researchers managed to successfully predict key sequences from inter-keystroke timings. While this is true for events that occur while you are typing at something like an xterm, it's not true while you type in a password. In that case the ssh client at your end collects the entire password, encrypts it, and transmits the whole thing when you hit . How are they going to determine inter-keystroke timings from that? Maybe the real trick is much cooler than what is shown in the article ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 17:49:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id E1A0937B40F for ; Wed, 22 Aug 2001 17:49:36 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CD66681D06; Wed, 22 Aug 2001 19:49:26 -0500 (CDT) Date: Wed, 22 Aug 2001 19:49:26 -0500 From: Alfred Perlstein To: Greg Black Cc: Matt Dillon , freebsd-hackers@freebsd.org Subject: Re: ssh password cracker - now this *is* cool! Message-ID: <20010822194926.U81307@elvis.mu.org> References: <200108222330.f7MNUUj80882@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gjb@gbch.net on Thu, Aug 23, 2001 at 10:45:07AM +1000 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 * Greg Black [010822 19:46] wrote: > Matt Dillon wrote: > > | This gets an 'A' on my cool-o-meter. > | > | http://www.vnunet.com/News/1124839 > > The real research might be interesting, but the information in > the article seems to be wrong. It says: > > Each keystroke from a user is immediately sent to the target > machine as a separate IP packet. By performing a statistical > study on a user's typing patterns, and applying a key > sequence prediction algorithm, the researchers managed to > successfully predict key sequences from inter-keystroke > timings. > > While this is true for events that occur while you are typing at > something like an xterm, it's not true while you type in a > password. In that case the ssh client at your end collects the > entire password, encrypts it, and transmits the whole thing when > you hit . > > How are they going to determine inter-keystroke timings from > that? Maybe the real trick is much cooler than what is shown in > the article ... No, the idea is that one may have ssh'd into a remote host that's trusted, and there the user is typing a password to access something from the trusted host. One could do the statistical analysis then. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 18: 0:27 2001 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 ABD6437B428 for ; Wed, 22 Aug 2001 17:59:41 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f7N0xf798475 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Aug 2001 20:59:41 -0400 (EDT) (envelope-from bicknell) Date: Wed, 22 Aug 2001 20:59:41 -0400 From: Leo Bicknell To: freebsd-hackers@FreeBSD.ORG Subject: Re: ssh password cracker - now this *is* cool! Message-ID: <20010822205941.A98321@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , freebsd-hackers@FreeBSD.ORG References: <200108222330.f7MNUUj80882@earth.backplane.com> <20010822195508.B93930@ussenterprise.ufp.org> <200108230010.f7N0AGf27563@intruder.bmah.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108230010.f7N0AGf27563@intruder.bmah.org>; from bmah@FreeBSD.ORG on Wed, Aug 22, 2001 at 05:10:16PM -0700 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 On Wed, Aug 22, 2001 at 05:10:16PM -0700, Bruce A. Mah wrote: > > Several people on other mailing lists have pointed out that Nagle > > should make this much harder, although it's unclear how Nagle and > > ssh interact. So far that has resulted in a number of degenerating > > discussions of how things work. Of course, Nagle will not help > > between two machines on the same ethernet segment, but probably > > would make the process described in the paper much harder. > > Indeed. They also didn't discuss (or I didn't see it) the effects of > queueing or jitter in the network on their scheme. I just had a thought. It appears from the discussion that SSH encrypts things (internal to ssh) in whatever unit is handed to the encryption routine, that is something like: for(;;) { read(stdin, buffer); encrypt(buffer); write(network, buffer); } So, if read returns a single character, it encrypts a single character and sends it. This results in the 20 byte packets in the article. Now, 20 bytes is small enough that Nagle might combine two of them into a single 40 byte packet or similar making this harder. That said, it would be much harder if something similar to Nagle was done in ssh: for (;;) { timer = gettime(); while ((len(buffer) < 20) && ((gettime() - timer) < 20ms)) { read(stdin, buffer); } encrypt(buffer); write(network, buffer); } This should allow two or three characters to go into a single block (which would probably still be 20 bytes) and completely throw off the method they were using. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 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 Wed Aug 22 18: 2:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 74CC637B412 for ; Wed, 22 Aug 2001 18:02:26 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 415C381D06; Wed, 22 Aug 2001 20:02:26 -0500 (CDT) Date: Wed, 22 Aug 2001 20:02:26 -0500 From: Alfred Perlstein To: Leo Bicknell Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ssh password cracker - now this *is* cool! Message-ID: <20010822200226.W81307@elvis.mu.org> References: <200108222330.f7MNUUj80882@earth.backplane.com> <20010822195508.B93930@ussenterprise.ufp.org> <200108230010.f7N0AGf27563@intruder.bmah.org> <20010822205941.A98321@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010822205941.A98321@ussenterprise.ufp.org>; from bicknell@ufp.org on Wed, Aug 22, 2001 at 08:59:41PM -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 * Leo Bicknell [010822 20:00] wrote: > On Wed, Aug 22, 2001 at 05:10:16PM -0700, Bruce A. Mah wrote: > > > Several people on other mailing lists have pointed out that Nagle > > > should make this much harder, although it's unclear how Nagle and > > > ssh interact. So far that has resulted in a number of degenerating > > > discussions of how things work. Of course, Nagle will not help > > > between two machines on the same ethernet segment, but probably > > > would make the process described in the paper much harder. > > > > Indeed. They also didn't discuss (or I didn't see it) the effects of > > queueing or jitter in the network on their scheme. > > I just had a thought. It appears from the discussion that SSH encrypts > things (internal to ssh) in whatever unit is handed to the encryption > routine, that is something like: > > for(;;) { > read(stdin, buffer); > encrypt(buffer); > write(network, buffer); > } > > So, if read returns a single character, it encrypts a single character > and sends it. This results in the 20 byte packets in the article. Now, > 20 bytes is small enough that Nagle might combine two of them into a > single 40 byte packet or similar making this harder. That said, it would > be much harder if something similar to Nagle was done in ssh: > > for (;;) { > timer = gettime(); > while ((len(buffer) < 20) && ((gettime() - timer) < 20ms)) { > read(stdin, buffer); > } > encrypt(buffer); > write(network, buffer); > } > > This should allow two or three characters to go into a single block (which > would probably still be 20 bytes) and completely throw off the method they > were using. I think introducing any sort of latency would really suck, instead you might want to consider the idea (as I've already suggested) of injecting false 'empty' packets into the stream to throw off this sort of cryptoanalysis. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 18: 5: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id C5DA737B420 for ; Wed, 22 Aug 2001 18:04:34 -0700 (PDT) (envelope-from gjb@gbch.net) Received: (qmail 30702 invoked by uid 1001); 23 Aug 2001 11:04:28 +1000 Message-ID: X-Posted-By: GJB-Post 2.21 16-Jun-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Thu, 23 Aug 2001 11:04:28 +1000 From: Greg Black To: Alfred Perlstein Cc: Matt Dillon , freebsd-hackers@freebsd.org Subject: Re: ssh password cracker - now this *is* cool! References: <200108222330.f7MNUUj80882@earth.backplane.com> <20010822194926.U81307@elvis.mu.org> In-reply-to: <20010822194926.U81307@elvis.mu.org> of Wed, 22 Aug 2001 19:49:26 EST 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 Alfred Perlstein wrote: | * Greg Black [010822 19:46] wrote: | > Matt Dillon wrote: | > | This gets an 'A' on my cool-o-meter. | > | | > | http://www.vnunet.com/News/1124839 | > | > The real research might be interesting, but the information in | > the article seems to be wrong. It says: | > | > Each keystroke from a user is immediately sent to the target | > machine as a separate IP packet. By performing a statistical | > study on a user's typing patterns, and applying a key | > sequence prediction algorithm, the researchers managed to | > successfully predict key sequences from inter-keystroke | > timings. | > | > While this is true for events that occur while you are typing at | > something like an xterm, it's not true while you type in a | > password. In that case the ssh client at your end collects the | > entire password, encrypts it, and transmits the whole thing when | > you hit . | > | > How are they going to determine inter-keystroke timings from | > that? Maybe the real trick is much cooler than what is shown in | > the article ... | | No, the idea is that one may have ssh'd into a remote host that's | trusted, and there the user is typing a password to access something | from the trusted host. | | One could do the statistical analysis then. Ah, I see. That's something that's on my list of things not to do, so I didn't consider it. My rule is never to type passwords once I'm logged into a host; and even if I have to type another ssh password to jump to another host that needs a password, my method is to type the password locally on the physical trusted machine I'm using and then cut and paste it into the application that's waiting for it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 19:29: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 14A3D37B405; Wed, 22 Aug 2001 19:28:57 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7N2Ssq45869; Wed, 22 Aug 2001 20:28:55 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7N2SqW80434; Wed, 22 Aug 2001 20:28:53 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108230228.f7N2SqW80434@harmony.village.org> To: simond@irrelevant.org Subject: Re: 4.4-RC NFS panic Cc: Andre Albsmeier , David Malone , walter@pelissero.org, John Baldwin , net@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 22 Aug 2001 08:13:35 BST." <20010822081335.A48043@irrelevant.org> References: <20010822081335.A48043@irrelevant.org> <20010821110203.A24141@curry.mchp.siemens.de> <15233.40823.749512.643101@hyde.lpds.sublink.org> <200108210935.aa87782@salmon.maths.tcd.ie> <20010821110203.A24141@curry.mchp.siemens.de> <200108210907.f7L97XW64198@harmony.village.org> <20010821122430.A25855@curry.mchp.siemens.de> Date: Wed, 22 Aug 2001 20:28:52 -0600 From: Warner Losh 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 <20010822081335.A48043@irrelevant.org> simond@irrelevant.org writes: : I've been having similar problems with my 4.4-RC Vaio F807K whenever I : do a lot of NFS over my wi0 (Buffalo wireless card), every so often my : laptop just completely freezes. I think that might be due to a bug in the shared interrupt code that Ian Dowse sent me about earlier today. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 19:30:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 15E8137B408; Wed, 22 Aug 2001 19:30:00 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7N2Twq45883; Wed, 22 Aug 2001 20:29:58 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7N2TuW80458; Wed, 22 Aug 2001 20:29:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108230229.f7N2TuW80458@harmony.village.org> To: sos@freebsd.dk Subject: Re: tunable support for ata interrupt sharing Cc: Peter Pentchev , Brooks Davis , sos@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 22 Aug 2001 11:46:27 +0200." <200108220946.f7M9kRP10043@freebsd.dk> References: <200108220946.f7M9kRP10043@freebsd.dk> Date: Wed, 22 Aug 2001 20:29:56 -0600 From: Warner Losh 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 <200108220946.f7M9kRP10043@freebsd.dk> S ren Schmidt writes: : and I dont know exactly how close 4.4 is to closure. My guess is that Jordan is going to wind up slipping the final release at least a week. But it is just a guess. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 19:39:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 0A47B37B406 for ; Wed, 22 Aug 2001 19:39:51 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (root@spare0.gsoft.com.au [203.38.152.114]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA06809; Thu, 23 Aug 2001 12:09:41 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.7 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010822173753.A11906@heechee.tobez.org> Date: Thu, 23 Aug 2001 12:09:41 +0930 (CST) From: "Daniel O'Connor" To: Anton Berezin Subject: RE: VM statistics per process? Cc: hackers@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 22-Aug-2001 Anton Berezin wrote: > will provide me with the number of resident pages. But I'd like to be > able to also get the number of active and inactive pages belonging to a > particular process. What should I do in order to get this information? The mincore() system call does this (the manpage in -stable is wrong, but may have recently been fixed?). You could steal the code from that I guess. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 19:43: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CA03537B408 for ; Wed, 22 Aug 2001 19:42:46 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7N2ggq45910; Wed, 22 Aug 2001 20:42:42 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7N2gfW80510; Wed, 22 Aug 2001 20:42:42 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108230242.f7N2gfW80510@harmony.village.org> To: Thierry Herbelot Subject: Re: clock synchronization quality via NTP ? Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 22 Aug 2001 21:47:34 +0200." <3B840C56.BDB7424D@herbelot.com> References: <3B840C56.BDB7424D@herbelot.com> Date: Wed, 22 Aug 2001 20:42:41 -0600 From: Warner Losh 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 <3B840C56.BDB7424D@herbelot.com> Thierry Herbelot writes: : I know FreeBSD can be used with great success for timing solutions (at : least two core members do it ?). Well, there's one core member, and a second committer. Or was until a few days ago... : has someone some performance data of the quality of system clock : synchronization, while using NTPd with a GPS reveiver and a hard 1PPS : signal ? : : More precisely : is it reasonable to hope having a system clock not : farther from the GPS clock by more than 50 micro-seconds ? It depends on the machine. We had troubles with 486-class hardware getting below a tens microseconds for extended periods of time. Part of this was due resolution of the timer used in the sytem. Part of it was due to thermal variance in the temperature. Part of it was due to the extremely crappy oscillator that was on the board. And we also had to hack the parallel port driver to use fast interrupts. Otherwise the interrupt latency variance caused too much jitter. Or at least enough jitter to measure and be concerned about. We've not repated the experiment now that pentium class hardware is available, which we think will yield much better results. PC hardware really sucks for timing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 19:43:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5E47137B407 for ; Wed, 22 Aug 2001 19:43:21 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7N2hKq45917; Wed, 22 Aug 2001 20:43:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7N2hJW80529; Wed, 22 Aug 2001 20:43:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108230243.f7N2hJW80529@harmony.village.org> To: djohnson Subject: Re: pci_get_devid() Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 22 Aug 2001 14:22:52 MDT." <3B84149C.8DD7F30B@faradayco.com> References: <3B84149C.8DD7F30B@faradayco.com> Date: Wed, 22 Aug 2001 20:43:19 -0600 From: Warner Losh 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 <3B84149C.8DD7F30B@faradayco.com> djohnson writes: : little application that gives a detailed enumeration of the PCI bus : using BIOS calls. Thanks in advance. PCI BUS ENUMERATION WITH BIOS CALLS SUCKS. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 19:45:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 24C5337B405 for ; Wed, 22 Aug 2001 19:45:26 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7N2jOq45928; Wed, 22 Aug 2001 20:45:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7N2jOW80551; Wed, 22 Aug 2001 20:45:24 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108230245.f7N2jOW80551@harmony.village.org> To: Wilko Bulte Subject: Re: clock synchronization quality via NTP ? Cc: Thierry Herbelot , hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 22 Aug 2001 22:50:25 +0200." <20010822225025.A33131@freebie.xs4all.nl> References: <20010822225025.A33131@freebie.xs4all.nl> <3B840C56.BDB7424D@herbelot.com> Date: Wed, 22 Aug 2001 20:45:24 -0600 From: Warner Losh 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 <20010822225025.A33131@freebie.xs4all.nl> Wilko Bulte writes: : On Wed, Aug 22, 2001 at 09:47:34PM +0200, Thierry Herbelot wrote: : > Hello, : > : > I know FreeBSD can be used with great success for timing solutions (at : > least two core members do it ?). : > : > has someone some performance data of the quality of system clock : > synchronization, while using NTPd with a GPS reveiver and a hard 1PPS : > signal ? : > : > More precisely : is it reasonable to hope having a system clock not : > farther from the GPS clock by more than 50 micro-seconds ? : : Talk to Poul-Henning, he is the clock/time expert (phk@FreeBSD.org). : Poul used to have some nice Web pages around on this subject but they : were killed in a disk crash IIRC. http://phk.freebsd.dk/rover.html used to be that URL... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 22 20:25:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.halplant.com (24-168-203-47.wo.cox.rr.com [24.168.203.47]) by hub.freebsd.org (Postfix) with ESMTP id D7B6B37B408 for ; Wed, 22 Aug 2001 20:25:04 -0700 (PDT) (envelope-from A.J.Caines@halplant.com) Received: by mail.halplant.com (Postfix, from userid 1001) id 3273C20FE; Wed, 22 Aug 2001 23:25:03 -0400 (EDT) Date: Wed, 22 Aug 2001 23:25:03 -0400 From: Andrew J Caines To: FreeBSD Hackers Subject: Mounting FAT16 on USB connected Rio 600 Message-ID: <20010822232503.E431@hal9000.servehttp.com> Reply-To: Andrew J Caines Mail-Followup-To: FreeBSD Hackers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: H.A.L. Plant X-Powered-by: FreeBSD 4.4-RC X-PGP-Fingerprint: C59A 2F74 1139 9432 B457 0B61 DDF2 AA61 67C3 18A1 Importance: 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 Hackers, The overwhelming lack of response on -questions suggests I might do better here. I though this would be an easy one. In short, I simply want to know what device to mount and what to do get that device configured. I have a Rio 600 MP3 player connected via USB. The device is recognised by the system - specifically usbd - however the (SCSI) disk device which I expect to appear and expect to be able to mount as an msdos filesystem does not. I have both IDE and SCSI disks in this box, have all drivers and filesystems compiled into the kernel, have extra disk device special files in /dev and start usbd at boot. I have ad0, da0 and da1 devices for disks, so would expect da2 to be the `next' disk created for the Rio, however the system doesn't recognise any da2 device and attempting to mount /dev/da2s1 gives "Device not configured". # ls /dev/[ad][ad][0-9]s1 /dev/ad0s1 /dev/ad2s1 /dev/da0s1 /dev/da2s1 /dev/ad1s1 /dev/ad3s1 /dev/da1s1 /dev/da3s1 The USB device appears as expected and disconnection and reconnection are picked up: # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 0x0100 port 1 powered port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 /kernel: ugen0: at uhub0 port 2 (addr 2) disconnected /kernel: ugen0: detached /kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 I've tried rescanning and examining devices on the SCSI bus with camcontrol to no avail: # camcontrol rescan 0 Re-scan of bus 0 was successful # camcontrol rescan 1 camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument # camcontrol devlist -v scbus0 on sym0 bus 0: at scbus0 target 1 lun 0 (pass0,da0) at scbus0 target 2 lun 0 (pass1,da1) < > at scbus0 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) # camcontrol periphlist da0 pass0: generation: 8 index: 1 status: MORE da0: generation: 8 index: 2 status: LAST # camcontrol periphlist da1 pass1: generation: 8 index: 1 status: MORE da1: generation: 8 index: 2 status: LAST # camcontrol periphlist da2 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da2 doesn't exist I have not previously used USB, so I hope my problem is simple ignorance. I've not found anything by way of documentation which puts all the pieces together. Kernel config for USB and disk subsystem: options MSDOSFS # MS DOS File System device scbus # SCSI bus device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device sym # NCR/Symbios Logic (newer chipsets) device da # Direct Access (disks) device pass # Passthrough device (direct SCSI access) device usb # General USB code (mandatory for USB) device ugen # Generic USB device driver device umass # Disks/Mass storage device uhci # UHCI PCI->USB interface Here's the trimmed dmesg output: uhci0: port 0xfca0-0xfcbf irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 sym0: <875> port 0xf400-0xf4ff mem 0xfedfe000-0xfedfefff,0xfedff800-0xfedff8ff irq 7 at device 15.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking orm0: