From owner-freebsd-hackers Sun Aug 5 1:18:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by hub.freebsd.org (Postfix) with ESMTP id 3B58037B401 for ; Sun, 5 Aug 2001 01:18:48 -0700 (PDT) (envelope-from archer@whichever.org) Received: from 207-172-201-44.s44.as1.xnb.nj.dialup.rcn.com ([207.172.201.44] helo=unknown.whichever.org) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.32 #2) id 15TJ7W-0000Ao-00 for freebsd-hackers@freebsd.org; Sun, 05 Aug 2001 04:18:47 -0400 Received: (from archer@localhost) by unknown.whichever.org (8.11.4/8.11.1) id f758IjT60048; Sun, 5 Aug 2001 04:18:45 -0400 (EDT) (envelope-from archer) Date: Sun, 5 Aug 2001 04:18:45 -0400 (EDT) Message-Id: <200108050818.f758IjT60048@unknown.whichever.org> From: Alexander Litvin To: freebsd-hackers@freebsd.org Subject: Re: gethostbyXXXX_r() In-Reply-To: X-Newsgroups: unknown.freebsd.hackers User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-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! > > On Sat, 4 Aug 2001, Richard Seaman, Jr. wrote: > >> There are some gethostby_r, getnetby_r, ... etc routines in the >> linuxthreads port (/usr/ports/devel/linuxthreads/files). These >> came from the original linuxthreads package, and have no copyright >> on them. I never researched the copyright status of them, but >> I don't think they are GPL, though you might want to do further >> research on their history if you use them. > > gethostbyxxx_r can be taken from bind 8 Yes, bind8 has them, as well as thread-safe resolver library. Unfortunately, FreeBSD's implementation is based on much older bind, and has wandered quite a long way from it (INET6, kqueue in res_send, etc.) So, to take bind8's implementation and modify it to match FreeBSD stuff would be quite painful IMHO. What I did to some extent mimics bind8's implementation. I just went from other direction -- took what FreeBSD has and applied some ideas from bind8. I just need couple more days to make it presentable. As for bind9 -- this has AFAIK totally rewritten resolver, which doesn't even resemble bind8. IMHO, to incorporate it into FreeBSD might take a tremendous effort. -- #include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 3: 4:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-25.dis.org [216.240.45.25]) by hub.freebsd.org (Postfix) with ESMTP id 0A66D37B401; Sun, 5 Aug 2001 03:04:31 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f75A6ug06183; Sun, 5 Aug 2001 03:06:56 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108051006.f75A6ug06183@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: lists Cc: Mike Smith , Warner Losh , freebsd-hackers@freebsd.org Subject: Re: NewCard / pccbb In-reply-to: Your message of "Sat, 04 Aug 2001 11:32:54 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Aug 2001 03:06:56 -0700 From: Mike Smith Sender: owner-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 Mike, ok my pci->pcmcia bridge is in slot 0, my network card is in slot > 3, below are the dmesg outputs from both oldcard and newcard, Ok; this is different from the "linked" dmesg you were showing before, and what it's highlighting is the weakness in the algorithm that we use for picking an interrupt in the "I have no idea what is good" case. Try taking the "life is tough" loop in sys/i386/pci/pci_cfgreg.c :pci_cfgintr_virgin() and change it so that it just loops from 11 to 11, ie. for (i = 11; i < 12; i++) { ... I still haven't worked out a "good" way of dealing with this problem; the way we hand out device resources makes it difficult to know in advance which interrupts are good choices. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 10:50:42 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 EF4FF37B403; Sun, 5 Aug 2001 10:50:39 -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 f75HodX05629; Sun, 5 Aug 2001 10:50:39 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f75Hoce34726; Sun, 5 Aug 2001 10:50:38 -0700 (PDT) (envelope-from jdp) Date: Sun, 5 Aug 2001 10:50:38 -0700 (PDT) Message-Id: <200108051750.f75Hoce34726@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: msmith@freebsd.org Subject: Re: Page Coloring In-Reply-To: <200108030347.f733lIC01436@mass.dis.org> References: <200108030347.f733lIC01436@mass.dis.org> 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 <200108030347.f733lIC01436@mass.dis.org>, Mike Smith wrote: > > It looks about right, but page colouring is pointless unless and until we > can determine the processor cache characteristics at runtime. > > Which we can't. Why can't we do this at least on the i386 with the CPUID instruction, initial %eax == 2? It returns cache size, associativity, and line size for both the L1 and L2 caches. As far as I can tell, it works for the Pentium Pro and subsequent processors. 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 Sun Aug 5 12:14: 1 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 DCF7D37B401; Sun, 5 Aug 2001 12:13:57 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f75JDir81853; Sun, 5 Aug 2001 12:13:44 -0700 (PDT) (envelope-from dillon) Date: Sun, 5 Aug 2001 12:13:44 -0700 (PDT) From: Matt Dillon Message-Id: <200108051913.f75JDir81853@earth.backplane.com> To: John Polstra Cc: hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: Page Coloring References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.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 :In article <200108030347.f733lIC01436@mass.dis.org>, :Mike Smith wrote: :> :> It looks about right, but page colouring is pointless unless and until we :> can determine the processor cache characteristics at runtime. :> :> Which we can't. : :Why can't we do this at least on the i386 with the CPUID instruction, :initial %eax == 2? It returns cache size, associativity, and line :size for both the L1 and L2 caches. As far as I can tell, it works :for the Pentium Pro and subsequent processors. : :John :-- : John Polstra jdp@polstra.com Well, first of all the page coloring is not pointless with the sizes hardwired. The cache characteristics do not have to match exactly for page coloring to work. The effectiveness is like a log-graph, and you don't lose a lot by guessing wrong. Once you get past a designated cache size of 4-pages or so you've already reaped 90% of the benefit on systems which use N-way (2, 4, 8) associative caches (which is most systems these days). For systems with direct-mapped caches you reap 90% of the benefits once you get past 16 pages or so. Since most L1 caches these days are at least 16K and most L2 caches these days are at least 64K (and often much higher, such as on the IA32), our hardwired page coloring constants wind up being about 95% effective across the entire range of chips our OS currently runs on. -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 5 12:18: 5 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 865BD37B401 for ; Sun, 5 Aug 2001 12:17:58 -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 f75JHqX06017; Sun, 5 Aug 2001 12:17:52 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f75JHqn34961; Sun, 5 Aug 2001 12:17:52 -0700 (PDT) (envelope-from jdp) Date: Sun, 5 Aug 2001 12:17:52 -0700 (PDT) Message-Id: <200108051917.f75JHqn34961@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: dillon@earth.backplane.com Subject: Re: Page Coloring In-Reply-To: <200108051913.f75JDir81853@earth.backplane.com> References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.com> <200108051913.f75JDir81853@earth.backplane.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200108051913.f75JDir81853@earth.backplane.com>, Matt Dillon wrote: > :In article <200108030347.f733lIC01436@mass.dis.org>, > :Mike Smith wrote: > :> > :> It looks about right, but page colouring is pointless unless and until we > :> can determine the processor cache characteristics at runtime. > :> > :> Which we can't. > : > :Why can't we do this at least on the i386 with the CPUID instruction, > :initial %eax == 2? It returns cache size, associativity, and line > :size for both the L1 and L2 caches. As far as I can tell, it works > :for the Pentium Pro and subsequent processors. > : > :John > :-- > : John Polstra jdp@polstra.com > > Well, first of all the page coloring is not pointless with the > sizes hardwired. The cache characteristics do not have to > match exactly for page coloring to work. The effectiveness is > like a log-graph, and you don't lose a lot by guessing wrong. > Once you get past a designated cache size of 4-pages or so you've > already reaped 90% of the benefit on systems which use N-way (2, 4, 8) > associative caches (which is most systems these days). For systems with > direct-mapped caches you reap 90% of the benefits once you get past > 16 pages or so. > > Since most L1 caches these days are at least 16K and most L2 caches > these days are at least 64K (and often much higher, such as on the IA32), > our hardwired page coloring constants wind up being about 95% effective > across the entire range of chips our OS currently runs on. Yes, I understand that. I'm just trying to find out why Mike keeps saying we cannot determine the processor cache characteristics at runtime. 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 Sun Aug 5 12:20:46 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 08AD637B405 for ; Sun, 5 Aug 2001 12:20:40 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f75JKa581920; Sun, 5 Aug 2001 12:20:36 -0700 (PDT) (envelope-from dillon) Date: Sun, 5 Aug 2001 12:20:36 -0700 (PDT) From: Matt Dillon Message-Id: <200108051920.f75JKa581920@earth.backplane.com> To: Chad David Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Page Coloring References: <20010802120335.A11520@colnta.acns.ab.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :If I added this to a man page would I be telling the truth :). : :Note, these are my notes and not the exact text that I would :add, and I have not bother with anything to do with object :coloring etc. I just want to make sure I've got this part :down. : :Chad It's a good description but it might be better to simplify it a bit. You don't need to go into that level of detail. There is a short page coloring explanation at the end of my VM article which might be more suitable to a man page: http://www.daemonnews.org/200001/freebsd_vm.html -Matt (quoted from the article): Ok, so now onto page coloring: All modern memory caches are what are known as *physical* caches. They cache physical memory addresses, not virtual memory addresses. This allows the cache to be left alone across a process context switch, which is very important. But in the UNIX world you are dealing with virtual address spaces, not physical address spaces. Any program you write will see the virtual address space given to it. The actual *physical* pages underlying that virtual address space are not necessarily physically contiguous! In fact, you might have two pages that are side by side in a processes address space which wind up being at offset 0 and offset 128K in *physical* memory. A program normally assumes that two side-by-side pages will be optimally cached. That is, that you can access data objects in both pages without having them blow away each other's cache entry. But this is only true if the physical pages underlying the virtual address space are contiguous (insofar as the cache is concerned). This is what Page coloring does. Instead of assigning *random* physical pages to virtual addresses, which may result in non-optimal cache performance , Page coloring assigns *reasonably-contiguous* physical pages to virtual addresses. Thus programs can be written under the assumption that the characteristics of the underlying hardware cache are the same for their virtual address space as they would be if the program had been run directly in a physical address space. Note that I say 'reasonably' contiguous rather than simply 'contiguous'. From the point of view of a 128K direct mapped cache, the physical address 0 is the same as the physical address 128K. So two side-by-side pages in your virtual address space may wind up being offset 128K and offset 132K in physical memory, but could also easily be offset 128K and offset 4K in physical memory and still retain the same cache performance characteristics. So page-coloring does *NOT* have to assign truely contiguous pages of physical memory to contiguous pages of virtual memory, it just needs to make sure it assigns contiguous pages from the point of view of cache performance and operation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 12:29:51 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 8126937B401 for ; Sun, 5 Aug 2001 12:29:43 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f75JTgF82008; Sun, 5 Aug 2001 12:29:42 -0700 (PDT) (envelope-from dillon) Date: Sun, 5 Aug 2001 12:29:42 -0700 (PDT) From: Matt Dillon Message-Id: <200108051929.f75JTgF82008@earth.backplane.com> To: John Polstra Cc: hackers@freebsd.org Subject: Re: Page Coloring References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.com> <200108051913.f75JDir81853@earth.backplane.com> <200108051917.f75JHqn34961@vashon.polstra.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 :> Since most L1 caches these days are at least 16K and most L2 caches :> these days are at least 64K (and often much higher, such as on the IA32), :> our hardwired page coloring constants wind up being about 95% effective :> across the entire range of chips our OS currently runs on. : :Yes, I understand that. I'm just trying to find out why Mike keeps :saying we cannot determine the processor cache characteristics at :runtime. : :John :-- : John Polstra jdp@polstra.com You can find out from the cpuid or something like that, but it's probably easier to simply do it programmatically, or not bother at all. It's not worth the effort. We would not reap any additional benefit from knowing. It is interesting to note that one effect of the page-coloring code is that the VM CACHE and FREE VM page queues are actually multi-queues, which means that when I extend the SMP locking down into them we will wind up with fine-grained locking for memory allocations. But before I can even begin contemplating that I have to change the way the vm_page BUSY'ing stuff works so page operations (such as allocations) can occur without having to hold long term mutexes. -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 5 12:34:36 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 AB01637B401 for ; Sun, 5 Aug 2001 12:34:30 -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 f75JYTX06173; Sun, 5 Aug 2001 12:34:29 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f75JYSo35024; Sun, 5 Aug 2001 12:34:28 -0700 (PDT) (envelope-from jdp) Date: Sun, 5 Aug 2001 12:34:28 -0700 (PDT) Message-Id: <200108051934.f75JYSo35024@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: dillon@earth.backplane.com Subject: Re: Page Coloring In-Reply-To: <200108051929.f75JTgF82008@earth.backplane.com> References: <200108030347.f733lIC01436@mass.dis.org> <200108051913.f75JDir81853@earth.backplane.com> <200108051917.f75JHqn34961@vashon.polstra.com> <200108051929.f75JTgF82008@earth.backplane.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200108051929.f75JTgF82008@earth.backplane.com>, Matt Dillon wrote: > :Yes, I understand that. I'm just trying to find out why Mike keeps > :saying we cannot determine the processor cache characteristics at > :runtime. > : > :John > > You can find out from the cpuid or something like that, Yes. As I said, you can find out from the CPUID instruction by passing it the value 2 in %eax. > but it's probably easier to simply do it programmatically, or > not bother at all. It's not worth the effort. We would not > reap any additional benefit from knowing. Opinions on that seem to vary wildly. Mike said just the opposite. Since that was not the point I addressed, I'll let the two of you debate it out. 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 Sun Aug 5 12:55:50 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 C0D5437B403 for ; Sun, 5 Aug 2001 12:55:47 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f75Jtk882156; Sun, 5 Aug 2001 12:55:46 -0700 (PDT) (envelope-from dillon) Date: Sun, 5 Aug 2001 12:55:46 -0700 (PDT) From: Matt Dillon Message-Id: <200108051955.f75Jtk882156@earth.backplane.com> To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time 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 :I should have guessed the reason. Matthew Dillon answered this question on :Fri, 2 Jun 2000 as follows: : : : The VM routines that manage pages associated with objects are not : protected against interrupts, so interrupts aren't allowed to change : page-object associations. Otherwise an interrupt at just the wrong : time could corrupt the mainline kernel VM code. : : :On Thu, 2 Aug 2001, Zhihui Zhang wrote: : :> :> FreeBSD can not allocate from the PQ_CACHE queue in an interrupt context. :> Can anyone explain it to me why this is the case? :> :> :> Thanks, Yes, that is precisely the reason. In -current this all changes, though, since interrupts are now threads. *But*, that said, interrupts cannot really afford to hold mutexes that might end up blocking them for long periods of time so I would still recommend that interrupt code not attempt to allocate pages out of PQ_CACHE. -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 5 14:39:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 23AFD37B401 for ; Sun, 5 Aug 2001 14:39:45 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id f75LX8X03342; Sun, 5 Aug 2001 22:33:08 +0100 (BST) (envelope-from nik) Date: Sun, 5 Aug 2001 22:33:08 +0100 From: Nik Clayton To: Matt Dillon Cc: Chad David , freebsd-hackers@FreeBSD.ORG Subject: Re: Page Coloring Message-ID: <20010805223308.D3254@canyon.nothing-going-on.org> References: <20010802120335.A11520@colnta.acns.ab.ca> <200108051920.f75JKa581920@earth.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="C+ts3FVlLX8+P6JN" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108051920.f75JKa581920@earth.backplane.com>; from dillon@earth.backplane.com on Sun, Aug 05, 2001 at 12:20:36PM -0700 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --C+ts3FVlLX8+P6JN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 05, 2001 at 12:20:36PM -0700, Matt Dillon wrote: > It's a good description but it might be better to simplify it a bit. > You don't need to go into that level of detail. There is a short > page coloring explanation at the end of my VM article which might > be more suitable to a man page: >=20 > http://www.daemonnews.org/200001/freebsd_vm.html That got pulled in to the documentation project a while ago, and can be found at http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/index.html This makes it pretty easy for us (you) to keep it up to date as you change FreeBSD's VM system. . . :-) N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --C+ts3FVlLX8+P6JN 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 iEYEARECAAYFAjttu5MACgkQk6gHZCw343WzpACfUaBt3C+EVzdDj7nO7g839ps4 4FgAnjMOdsg0FVDj6X/EV+bMAKeF4QUa =MWPP -----END PGP SIGNATURE----- --C+ts3FVlLX8+P6JN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 15:28:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (dhcp45-25.dis.org [216.240.45.25]) by hub.freebsd.org (Postfix) with ESMTP id CA71D37B401 for ; Sun, 5 Aug 2001 15:28:15 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f75MUu100891; Sun, 5 Aug 2001 15:30:56 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108052230.f75MUu100891@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Polstra Cc: hackers@freebsd.org, dillon@earth.backplane.com Subject: Re: Page Coloring In-reply-to: Your message of "Sun, 05 Aug 2001 12:17:52 PDT." <200108051917.f75JHqn34961@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Sun, 05 Aug 2001 15:30:56 -0700 From: Mike Smith Sender: owner-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, I understand that. I'm just trying to find out why Mike keeps > saying we cannot determine the processor cache characteristics at > runtime. Because I believed we couldn't. It appears I'm wrong. 8) The only question left really then is whether it's worth actually trying = to tune for cache size, or if our defaults are good enough, whether we = shouldn't just keep them as they are... -- = =2E.. every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 17:51:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp5ve.mailsrvcs.net (smtp5vepub.gte.net [206.46.170.26]) by hub.freebsd.org (Postfix) with ESMTP id 2E26C37B401; Sun, 5 Aug 2001 17:51:29 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net ([151.198.117.229]) by smtp5ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id AAA39685403; Mon, 6 Aug 2001 00:51:01 GMT Message-ID: <3B6DE9F4.FC8D46F8@bellatlantic.net> Date: Sun, 05 Aug 2001 20:51:00 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Matt Dillon Cc: John Polstra , hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: Page Coloring References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.com> <200108051913.f75JDir81853@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 Dillon wrote: > > Well, first of all the page coloring is not pointless with the > sizes hardwired. The cache characteristics do not have to > match exactly for page coloring to work. The effectiveness is > like a log-graph, and you don't lose a lot by guessing wrong. > Once you get past a designated cache size of 4-pages or so you've > already reaped 90% of the benefit on systems which use N-way (2, 4, 8) > associative caches (which is most systems these days). For systems with > direct-mapped caches you reap 90% of the benefits once you get past > 16 pages or so. If I remember correctly from reading a thesis (can't remember its author) on the page coloring which I believe widely introduced this concept, page coloring adds a lot of efficiency to the directly mapped caches but even for the 2-way caches is nearly pointless. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 17:55: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ranger.acns.ab.ca (h24-68-206-125.sbm.shawcable.net [24.68.206.125]) by hub.freebsd.org (Postfix) with ESMTP id 91D8E37B401; Sun, 5 Aug 2001 17:54:57 -0700 (PDT) (envelope-from davidc@ranger.acns.ab.ca) Received: (from davidc@localhost) by ranger.acns.ab.ca (8.11.5/8.11.3) id f760ssX33096; Sun, 5 Aug 2001 18:54:54 -0600 (MDT) (envelope-from davidc) Date: Sun, 5 Aug 2001 18:54:54 -0600 From: Chad David To: freebsd-hackers@freebsd.org Cc: Matt Dillon , Nik Clayton Subject: Re: Page Coloring Message-ID: <20010805185454.A32968@ranger.acns.ab.ca> Mail-Followup-To: freebsd-hackers@freebsd.org, Matt Dillon , Nik Clayton References: <20010802120335.A11520@colnta.acns.ab.ca> <200108051920.f75JKa581920@earth.backplane.com> <20010805223308.D3254@canyon.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010805223308.D3254@canyon.nothing-going-on.org>; from nik@freebsd.org on Sun, Aug 05, 2001 at 10:33:08PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Aug 05, 2001 at 10:33:08PM +0100, Nik Clayton wrote: > On Sun, Aug 05, 2001 at 12:20:36PM -0700, Matt Dillon wrote: > > It's a good description but it might be better to simplify it a bit. > > You don't need to go into that level of detail. There is a short > > page coloring explanation at the end of my VM article which might > > be more suitable to a man page: > > > > http://www.daemonnews.org/200001/freebsd_vm.html > > That got pulled in to the documentation project a while ago, and can be > found at > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/index.html > > This makes it pretty easy for us (you) to keep it up to date as you > change FreeBSD's VM system. . . Thanks, I will use some of this text if I can, and be sure to give Matt credit. If that was too much detail, is there a place for the detail? Next week I am going to attempt to determine the cache size via the cpuid instruction, and export some of the calculation parameters via sysctl (to help with some simulations that we are going to be doing). Given that nobody has done this yet, am I missing something that will bite me? The intel IA32 manuals seem to indicate that most of the (intel) cpu's in use today should support cpuid 2 lookup? Thanks. Chad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 18:29:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dns1.nettek-llc.com (cf464826-a.mdfrd1.or.home.com [24.12.176.164]) by hub.freebsd.org (Postfix) with ESMTP id B2D0F37B405 for ; Sun, 5 Aug 2001 18:29:23 -0700 (PDT) (envelope-from stevel@nettek-llc.com) Received: from nettek-llc.com (bock.nettek-llc.com [192.168.0.1]) by dns1.nettek-llc.com (8.11.4/8.11.4) with ESMTP id f761TN209281 for ; Sun, 5 Aug 2001 18:29:23 -0700 (PDT) (envelope-from stevel@nettek-llc.com) Message-ID: <3B6DF2F2.9080302@nettek-llc.com> Date: Sun, 05 Aug 2001 18:29:22 -0700 From: Steve Logue User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010703 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-hackers Subject: Linksys WDT11/WPC11 Combo 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 Sorry if this is a duplicate.... Hello, Does anyone have any patches for preliminary support of the Linksys WDT11/WPC11 wireless ethernet combo? The WDT card uses the PLX PCI9052 chipset and shows up under -STABLE's dmesg as: pci0: (vendor=0x16ab, dev=0x1102) at 19.0 irq 12 With what I have been reading so far on the PLX thread, I appear to have a different dev number. Most people have talked about dev=1101, but I have dev=1102. Is this a new rev of the board? How can I get this working? Patches for -CURRENT or -STABLE would be appreciated. -STEVEl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 19:27: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from security.za.net (security.za.net [196.2.146.22]) by hub.freebsd.org (Postfix) with ESMTP id 5612437B401; Sun, 5 Aug 2001 19:27:01 -0700 (PDT) (envelope-from lists@security.za.net) Received: from localhost (lists@localhost) by security.za.net (8.11.4/8.11.4) with ESMTP id f762Qv866924; Mon, 6 Aug 2001 04:26:57 +0200 (SAST) (envelope-from lists@security.za.net) Date: Mon, 6 Aug 2001 04:26:57 +0200 (SAST) From: lists To: Mike Smith Cc: Warner Losh , freebsd-hackers@freebsd.org Subject: Re: NewCard / pccbb In-Reply-To: <200108051006.f75A6ug06183@mass.dis.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 Hi Mike, I tried your suggestion below, and for some reason its still assigning the same interrupt (whichever one I pick) to both the network card and the wavelan card, and interstingly enough even if I remove one of them, its still trying to get a routeable interrupt and the wavelan still doesnt work. Any way that I can get this thing to give me a straight interrupt on all cards without trying to do funny irq routing? Thanks Andrew On Sun, 5 Aug 2001, Mike Smith wrote: > > Hi Mike, ok my pci->pcmcia bridge is in slot 0, my network card is in slot > > 3, below are the dmesg outputs from both oldcard and newcard, > > Ok; this is different from the "linked" dmesg you were showing before, > and what it's highlighting is the weakness in the algorithm that we use > for picking an interrupt in the "I have no idea what is good" case. > > Try taking the "life is tough" loop in sys/i386/pci/pci_cfgreg.c > :pci_cfgintr_virgin() and change it so that it just loops from 11 to 11, > ie. > > for (i = 11; i < 12; i++) { > ... > > I still haven't worked out a "good" way of dealing with this problem; the > way we hand out device resources makes it difficult to know in advance > which interrupts are good choices. 8( > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 19:52:18 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 0DD2337B401; Sun, 5 Aug 2001 19:52:16 -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 f762qEF14783; Sun, 5 Aug 2001 20:52:15 -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 f762qD103042; Sun, 5 Aug 2001 20:52:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108060252.f762qD103042@harmony.village.org> To: lists Subject: Re: NewCard / pccbb Cc: Mike Smith , freebsd-hackers@freebsd.org In-reply-to: Your message of "Mon, 06 Aug 2001 04:26:57 +0200." References: Date: Sun, 05 Aug 2001 20:52:13 -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 lists writes: : I tried your suggestion below, and for some reason its still assigning the : same interrupt (whichever one I pick) to both the network card and the : wavelan card, and interstingly enough even if I remove one of them, its : still trying to get a routeable interrupt and the wavelan still doesnt : work. Any way that I can get this thing to give me a straight interrupt : on all cards without trying to do funny irq routing? Unlike the ISA world, it is OK to use the same IRQ in the pci world. Of course, Mike will have to say if this is sane considering your PIR table. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 5 21: 0:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dirnafax (unknown [216.72.219.3]) by hub.freebsd.org (Postfix) with SMTP id A973437B405 for ; Sun, 5 Aug 2001 20:59:56 -0700 (PDT) (envelope-from empresas@cable.net.co) x-esmtp: 0 0 1 Message-ID: <2589087-2200181621319930@cable.net.co> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #00F06206106618006920 X-Priority: 3 Reply-To: empresas@cable.net.co From: "Empresas" To: freebsd-hackers@freebsd.org Subject: Base de Datos - 1.000 Empresas Date: Sun, 5 Aug 2001 21:13:19 -0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_94915C5ABAF209EF376268C8" X-SMTPExp-Version: 1, 0, 2, 13 X-SMTPExp-Registration: 00B0320C107602006905 Sender: owner-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_94915C5ABAF209EF376268C8 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset="US-ASCII" EMPRESAS - Base de datos con las 1.000 Empresas más grandes de Colombia (ventas superiores a $20.000 millones anuales), con los siguientes campos: razón social, sigla, Nit, dirección, teléfono, fax, actividad empresarial (código CIIU Rev. 3.0), número de empleados, ciudad y departamento, cifras de Activos, Patrimonio, Ventas y Utilidad para los últimos cinco años (Incluye cifras del año 2.000). Adicional a esta base se encuentra la base de datos de directivos y ejecutivos de estas empresas (más de 9.500), con los siguientes campos: nombre, cargo, área por cargos, dirección, teléfono y fax. Estas bases de datos se encuentran relacionadas, la APLICACION que las maneja permite hacer búsquedas simples o complejas por todos los campos, agrupa diferentes tipos de búsquedas, prepara e imprime reportes, rótulos y cartas, hace llamadas telefónicas y envía email's. La aplicación es totalmente autónoma, es decir no necesita ningún software adicional para su total desempeño en Windows 95 o superior. COMO VALOR AGREGADO le damos acceso a toda la información sobre COMERCIO EXTERIOR (27.000 importadores y 4.000 exportadores), a través de enlaces Vía Internet a MINCOMEX, PROEXPORT Y LA COMUNIDAD ANDINA. También le facilitamos la conexión a sus propios enlaces. PRESENTACION - Las bases de datos y la aplicación se entregan en un CD, que permite la auto-instalación. VALOR DEL CD - Col$100.000, los cuales se deben depositar en COLMENA en la cuenta de ahorros No. 0114500194215 a nombre de Directorio Nacional de Fax, copia de la consignación con las instrucciones de entrega enviarlas al Fax 6178102/6179073 Bogotá y el CD y la factura serán enviados al día siguiente vía Servientrega. Si ya adquirió la versión 500 Empresas deposite únicamente Col$50.000 Empresas - Tr. 51A No 123-01 Int. 10 - Tel. 6135184 - Fax 6178102/6179073 - empresas@elsitio.net.co - Bogotá Colombia Si desea ser removido de esta base de datos, responda a este mensaje indicando - remover - en el subject ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable EMPRESAS - Base de datos de las 500Empresas m=E1s grandes, (por ven= tas), del pa=EDs con los siguientes campos: raz=F3n social, sigla

EMPRESAS<= span style=3D'font-size:10=2E0pt;font-family:Arial;color:blue'> - Base de datos co= n las 1=2E000 Empresas m=E1s grandes de Colombia (ventas superiores a $20=2E000 mil= lones anuales), con los siguientes campos: raz=F3n social, sigla, Nit, direcci=F3n, tel=E9fono, fax, actividad empresarial (c=F3digo CIIU Rev=2E = 3=2E0), n=FAmero de empleados, ciudad y departamento, cifras de Activos, Patrimonio, Ventas= y Utilidad para los =FAltimos cinco a=F1os (Incluye cifras del a=F1o 2=2E000)=2E Adi= cional a esta base se encuentra la base de datos de directivos y ejecutivos de esta= s empresas (m=E1s de 9=2E500), con los siguientes campos: nombre, cargo, =E1= rea por cargos, direcci=F3n, tel=E9fono y fax=2E

 

Estas bases de datos se encuentran relacionadas, la APLICACION que las maneja permite hacer b=FAsquedas simpl= es o complejas por todos los campos, agrupa diferentes tipos de b=FAsquedas, prepara e im= prime reportes, r=F3tulos y cartas, hace llamadas telef=F3nicas y env=EDa email=92s=2E La aplicaci=F3n es totalmente aut=F3nom= a, es decir no necesita ning=FAn software adicional para su total desempe=F1o en Windows = 95 o superior=2E

 

COMO VALOR AGREGADO le damos acceso= a toda la informaci=F3n sobre COMERCIO EXTERIOR (27=2E000 importadores y 4=2E000 exportadores), a trav=E9s de enlaces V=EDa Internet a MINCOMEX, PROEXPORT = Y LA COMUNIDAD ANDINA=2E Tambi=E9n le facilitamos la conexi=F3n a sus propios e= nlaces=2E

 

PRESENTACION =96 Las bases de datos= y la aplicaci=F3n se entregan en un CD, que permite la auto-instalaci=F3n=2E

 

VALOR DEL CD=A0 - Col$100=2E000, los cuales se deben depositar en = COLMENA en la cuenta de ahorros No=2E 0114500194215 a nombre de Directorio Naciona= l de Fax, copia de la consignaci=F3n con las instrucciones de entrega enviarlas= al Fax 6178102/6179073 Bogot=E1 y el CD y la factura ser=E1n enviados al d=EDa si= guiente v=EDa Servientrega=2E Si ya adquiri=F3 la versi=F3n 500 Empresas deposite =FAnicamen= te Col$50=2E000

 

Empresas - Tr=2E 51A No 123-01 Int=2E 10 =96 Tel=2E 6135184 =96 Fax 6178102/6179073 =96 empresas@elsitio=2Enet=2Eco - Bogot=E1 Colombia

 

Si desea ser removido de esta base de datos, responda a este mensaje indicand= o =96 remover =96 en el subject

 

 

------=_NextPart_84815C5ABAF209EF376268C8-- ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-Description: image002.jpg Content-Id: <32600-2200181621347702285@cable.net.co> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/wAALCAJZAAgBAREA/8QAGQABAQEBAQEAAAAAAAAAAAAAAgEDAAUH/8QAFhABAQEAAAAA AAAAAAAAAAAAABES/90ABAAo/9oACAEBAAA/APSirFhFChQocOHDjSHGkaZPLTLSHDjSHChwoUKF FVVVXRUrn//Q+yIiIlGjRo0KNCs6FCs9M9BpnWdCs6FChQo0aNEalRK5/9k= ------=_NextPart_94915C5ABAF209EF376268C8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 0:41:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id A3A8837B408; Mon, 6 Aug 2001 00:41:50 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f767iI001843; Mon, 6 Aug 2001 00:44:18 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108060744.f767iI001843@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: lists Cc: Mike Smith , Warner Losh , freebsd-hackers@freebsd.org Subject: Re: NewCard / pccbb In-reply-to: Your message of "Mon, 06 Aug 2001 04:26:57 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 00:44:18 -0700 From: Mike Smith Sender: owner-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 tried your suggestion below, and for some reason its still assigning the > same interrupt (whichever one I pick) to both the network card and the > wavelan card, and interstingly enough even if I remove one of them, its > still trying to get a routeable interrupt and the wavelan still doesnt > work. Any way that I can get this thing to give me a straight interrupt > on all cards without trying to do funny irq routing? I'm sorry, I'm totally confused here. In the dmesg output you sent me, the cardbus bridge and ethernet were being set up with totally different interrupts by your BIOS; what you're saying here is completely inconsistent with that. I don't know what your problem is. You're not giving me enough information to do anything about it, though, so the situation won't improve. I need the $PIR table and dmesg output FROM THE SYSTEM THAT IS FAILING along with any other relevant data, like hardcoded pcic interrupts in your loader config, etc. And no, there's no such thing as "a straight interrupt". Please, never, ever use "doesn't work" in an email to me. Or if I ever meet you in person, I will hurt you a very great deal. Ok? Tell me *exactly* what you tried, and *exactly* what happened. If you don't remember, go back and do it again, and write it down this time. I get a lot of email. I don't have the faintest hope in hell of remembering all the details of your problem from one day to the next. Please keep all your context, and if I delete it from my replies (for brevity) just attach it to your next message back, ok? Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 0:45:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 301B937B408 for ; Mon, 6 Aug 2001 00:45:14 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f767ls001881; Mon, 6 Aug 2001 00:47:54 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108060747.f767ls001881@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Warner Losh Cc: lists , freebsd-hackers@freebsd.org Subject: Re: NewCard / pccbb In-reply-to: Your message of "Sun, 05 Aug 2001 20:52:13 MDT." <200108060252.f762qD103042@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 00:47:53 -0700 From: Mike Smith Sender: owner-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 lists w > rites: > : I tried your suggestion below, and for some reason its still assigning the > : same interrupt (whichever one I pick) to both the network card and the > : wavelan card, and interstingly enough even if I remove one of them, its > : still trying to get a routeable interrupt and the wavelan still doesnt > : work. Any way that I can get this thing to give me a straight interrupt > : on all cards without trying to do funny irq routing? > > Unlike the ISA world, it is OK to use the same IRQ in the pci world. > Of course, Mike will have to say if this is sane considering your PIR table. The $PIR table is really awful; it basically just says "all the standard interrupts are available everywhere except the IDE controller and one other place". We need a set of "preferential" interrupts, I think. However, I'm missing some other pieces of the picture here, which is really pissing me off. The dmesg output he sent me doesn't relate to this at all. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 1:17:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id CC92037B401 for ; Mon, 6 Aug 2001 01:17:16 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.4/8.11.4) id f76CXfB99967 for freebsd-hackers@freebsd.org; Mon, 6 Aug 2001 12:33:41 GMT (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108061233.f76CXfB99967@bugz.infotecs.ru> Subject: libmp To: freebsd-hackers@freebsd.org Date: Mon, 6 Aug 2001 12:33:40 +0000 (GMT) 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 Hello, I cvsup'ed 5.0-CURRENT yesterday, successfully compiled the kernel and tried to compile the rest. However, when doing make in the lib directory, it stops on libmp. The problem is that libmp uses include files from openssl/, and they are not present in my system, as I can see they don't come with freebsd. Of course I know how to install libssl, but is there any sense in using files that don't exist, so that user must install some third-party software to compile *distribution* component ? Or did my cvsup messed something up or am I missing something ? Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 1:31:22 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 474D837B408; Mon, 6 Aug 2001 01:31:20 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f768VI985471; Mon, 6 Aug 2001 01:31:18 -0700 (PDT) (envelope-from dillon) Date: Mon, 6 Aug 2001 01:31:18 -0700 (PDT) From: Matt Dillon Message-Id: <200108060831.f768VI985471@earth.backplane.com> To: Sergey Babkin Cc: John Polstra , hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: Page Coloring References: <200108030347.f733lIC01436@mass.dis.org> <200108051750.f75Hoce34726@vashon.polstra.com> <200108051913.f75JDir81853@earth.backplane.com> <3B6DE9F4.FC8D46F8@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 :If I remember correctly from reading a thesis (can't remember its :author) on the page coloring which I believe widely introduced this :concept, page coloring adds a lot of efficiency to the directly :mapped caches but even for the 2-way caches is nearly pointless. : :-SB For the most part, yes. 2-way set associative caches handle standard compiled programs reasonably well. 4-way set associative caches handle standard interpreted programs reasonably well. Page-coloring helps keep things consistent between program runs but typically has very little effect on machines which already have set-associative caches. The main thing is the consistency - for example, if you have a medium-sized buffer in memory which you are accessing randomly, page coloring will prevent degenerate cache cases that can occur in cases where the VM system (without coloring) happens to assign the same cache page to every page of the buffer. But you wouldn't notice unless your buffer had more then N pages (N = set associativity). For the same reason, 'random' also works fairly well (just in a less consistent way), which is why page coloring doesn't add much when doing a performance comparison on a system with a 2-way or better associative cache. -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 6 3:43:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 29B5B37B403 for ; Mon, 6 Aug 2001 03:43:29 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.4/8.11.4) id f76ExgM27300 for freebsd-hackers@freebsd.org; Mon, 6 Aug 2001 14:59:42 GMT (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108061459.f76ExgM27300@bugz.infotecs.ru> Subject: pam_ssh To: freebsd-hackers@freebsd.org Date: Mon, 6 Aug 2001 14:59:41 +0000 (GMT) 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 Hello, while trying to compile -current, I discovered some possible bug: when compiling libpam, it stops on libpam/modules/pam_ssh/pam_ssh.c, giving bunch of errors. The problem is that including security/pam_mod_misc.h seems wrong, it doesn't find it there. When I changed it to simple pam_mod_misc.h, everything compiled fine. Other modules refer to pam_mod_misc.h too, only pam_ssh.c for some strange reason refers to security/pam_mod_misc.h. If this really is a bug, would be good if someone would care ... Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 5:19:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (unknown [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id F384B37B401 for ; Mon, 6 Aug 2001 05:19:48 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 1961 invoked by uid 1000); 6 Aug 2001 12:18:28 -0000 Date: Mon, 6 Aug 2001 15:18:28 +0300 From: Peter Pentchev To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: libmp Message-ID: <20010806151828.B1107@ringworld.oblivion.bg> Mail-Followup-To: "Eugene L. Vorokov" , freebsd-hackers@freebsd.org References: <200108061233.f76CXfB99967@bugz.infotecs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108061233.f76CXfB99967@bugz.infotecs.ru>; from vel@bugz.infotecs.ru on Mon, Aug 06, 2001 at 12:33:40PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 06, 2001 at 12:33:40PM +0000, Eugene L. Vorokov wrote: > Hello, > > I cvsup'ed 5.0-CURRENT yesterday, successfully compiled the kernel and > tried to compile the rest. However, when doing make in the lib directory, > it stops on libmp. The problem is that libmp uses include files from > openssl/, and they are not present in my system, as I can see they > don't come with freebsd. Of course I know how to install libssl, but > is there any sense in using files that don't exist, so that user must > install some third-party software to compile *distribution* component ? > Or did my cvsup messed something up or am I missing something ? Errrrr... the OpenSSL sources *are* shipped with FreeBSD. Or at least they should be, if your CVSup is doing the right thing. Are you cvsup'ping the src-all collection, or the subcollections? There is no longer any need to *not* cvsup src-all, no matter if you are in an export-controlled environment or not - all the export restrictions on code included with FreeBSD have either expired, or (ISTR) been waived specifically for the FreeBSD distribution. So.. cvsup again, using the src-all collection, and see if you grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. Also, make sure that NOSECURE is NOT turned on in your make.conf. Hope that helps.. G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 5:24:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (unknown [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 065CF37B401 for ; Mon, 6 Aug 2001 05:24:22 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 2043 invoked by uid 1000); 6 Aug 2001 12:23:10 -0000 Date: Mon, 6 Aug 2001 15:23:10 +0300 From: Peter Pentchev To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: libmp Message-ID: <20010806152310.C1107@ringworld.oblivion.bg> Mail-Followup-To: "Eugene L. Vorokov" , freebsd-hackers@freebsd.org References: <200108061233.f76CXfB99967@bugz.infotecs.ru> <20010806151828.B1107@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010806151828.B1107@ringworld.oblivion.bg>; from roam@ringlet.net on Mon, Aug 06, 2001 at 03:18:28PM +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 Mon, Aug 06, 2001 at 03:18:28PM +0300, Peter Pentchev wrote: > On Mon, Aug 06, 2001 at 12:33:40PM +0000, Eugene L. Vorokov wrote: > > Hello, > > > > I cvsup'ed 5.0-CURRENT yesterday, successfully compiled the kernel and > > tried to compile the rest. However, when doing make in the lib directory, > > it stops on libmp. The problem is that libmp uses include files from > > openssl/, and they are not present in my system, as I can see they > > don't come with freebsd. Of course I know how to install libssl, but > > is there any sense in using files that don't exist, so that user must > > install some third-party software to compile *distribution* component ? > > Or did my cvsup messed something up or am I missing something ? > > Errrrr... the OpenSSL sources *are* shipped with FreeBSD. > Or at least they should be, if your CVSup is doing the right thing. > Are you cvsup'ping the src-all collection, or the subcollections? > There is no longer any need to *not* cvsup src-all, no matter if > you are in an export-controlled environment or not - all the export > restrictions on code included with FreeBSD have either expired, > or (ISTR) been waived specifically for the FreeBSD distribution. > > So.. cvsup again, using the src-all collection, and see if you > grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. > Also, make sure that NOSECURE is NOT turned on in your make.conf. > Of course, this should have been src/secure/lib/libssl/, but it is not really relevant in this case; src/secure/lib/libcrypto/ would be much more relevant :) G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 5:30:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 263B037B403 for ; Mon, 6 Aug 2001 05:30:20 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.5/8.11.4) id f76GkNS58698; Mon, 6 Aug 2001 16:46:23 GMT (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108061646.f76GkNS58698@bugz.infotecs.ru> Subject: Re: libmp To: roam@ringlet.net (Peter Pentchev) Date: Mon, 6 Aug 2001 16:46:22 +0000 (GMT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <20010806151828.B1107@ringworld.oblivion.bg> from "Peter Pentchev" at Aug 06, 2001 03:18:28 PM 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 > Errrrr... the OpenSSL sources *are* shipped with FreeBSD. > Or at least they should be, if your CVSup is doing the right thing. > Are you cvsup'ping the src-all collection, or the subcollections? > There is no longer any need to *not* cvsup src-all, no matter if > you are in an export-controlled environment or not - all the export > restrictions on code included with FreeBSD have either expired, > or (ISTR) been waived specifically for the FreeBSD distribution. > > So.. cvsup again, using the src-all collection, and see if you > grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. > Also, make sure that NOSECURE is NOT turned on in your make.conf. > > Hope that helps.. Hmm yes, it's there. But the snapshot I installed first doesn't have it (why ?). When I installed it manually prior to compiling libs, libmp compiles fine ... Btw, is there any guide of what is the proper order of compiling things after cvsup ? Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 5:38:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (unknown [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id B535637B405 for ; Mon, 6 Aug 2001 05:38:16 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 2290 invoked by uid 1000); 6 Aug 2001 12:37:05 -0000 Date: Mon, 6 Aug 2001 15:37:05 +0300 From: Peter Pentchev To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: libmp Message-ID: <20010806153705.B2110@ringworld.oblivion.bg> Mail-Followup-To: "Eugene L. Vorokov" , freebsd-hackers@freebsd.org References: <20010806151828.B1107@ringworld.oblivion.bg> <200108061646.f76GkNS58698@bugz.infotecs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108061646.f76GkNS58698@bugz.infotecs.ru>; from vel@bugz.infotecs.ru on Mon, Aug 06, 2001 at 04:46:22PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 06, 2001 at 04:46:22PM +0000, Eugene L. Vorokov wrote: > > Errrrr... the OpenSSL sources *are* shipped with FreeBSD. > > Or at least they should be, if your CVSup is doing the right thing. > > Are you cvsup'ping the src-all collection, or the subcollections? > > There is no longer any need to *not* cvsup src-all, no matter if > > you are in an export-controlled environment or not - all the export > > restrictions on code included with FreeBSD have either expired, > > or (ISTR) been waived specifically for the FreeBSD distribution. > > > > So.. cvsup again, using the src-all collection, and see if you > > grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. > > Also, make sure that NOSECURE is NOT turned on in your make.conf. > > > > Hope that helps.. > > Hmm yes, it's there. But the snapshot I installed first doesn't > have it (why ?). When I installed it manually prior to compiling libs, > libmp compiles fine ... Btw, is there any guide of what is the proper > order of compiling things after cvsup ? Yep, the src/UPDATING file. What do you mean, the snapshot did not have it? Did you really CVSup 5.0-current on a machine running an earlier version, or did you install from a pre-built 5.0-current snapshot? Or are you referring to the CVSup snapshot - in what sense did it "not have it" - there was no src/crypto/openssl/ directory, or there was no src/secure/lib/libcrypto/ directory, or the libcrypto Makefile did not install the OpenSSL header files files under /usr/obj/.../src/i386/usr/include/openssl? How exactly are you trying to compile things? What did you do after the CVSup run? And.. what version are you updating from? G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 6: 2:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 98CB337B401 for ; Mon, 6 Aug 2001 06:02:26 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.5/8.11.4) id f76HIoT59752; Mon, 6 Aug 2001 17:18:50 GMT (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108061718.f76HIoT59752@bugz.infotecs.ru> Subject: Re: libmp To: roam@ringlet.net (Peter Pentchev) Date: Mon, 6 Aug 2001 17:18:49 +0000 (GMT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <20010806153705.B2110@ringworld.oblivion.bg> from "Peter Pentchev" at Aug 06, 2001 03:37:05 PM 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 > > Hmm yes, it's there. But the snapshot I installed first doesn't > > have it (why ?). When I installed it manually prior to compiling libs, > > libmp compiles fine ... Btw, is there any guide of what is the proper > > order of compiling things after cvsup ? > > Yep, the src/UPDATING file. > > What do you mean, the snapshot did not have it? Did you really > CVSup 5.0-current on a machine running an earlier version, or did > you install from a pre-built 5.0-current snapshot? Or are you referring > to the CVSup snapshot - in what sense did it "not have it" - > there was no src/crypto/openssl/ directory, or there was no > src/secure/lib/libcrypto/ directory, or the libcrypto Makefile did > not install the OpenSSL header files files under > /usr/obj/.../src/i386/usr/include/openssl? > > How exactly are you trying to compile things? What did you do > after the CVSup run? And.. what version are you updating from? I first installed the snapshot 5.0-20010618-CURRENT. Then I installed cvsup and cvsup'ed src-all collection. When it was completed, I tried to recompile the kernel, but config was complaining that it's version doesn't match the kernel version, so I compiled and installed src/usr.sbin/config, then I configured and compiled kernel, it compiled fine. Then I rebooted and tried to compile the userland things. I was thinking that I must first install new include files, then compile and install libs and then executables. So I did make and make install in the src/include directory and tried to do the same in the src/lib, but it stopped on libmp. At that point I had no /usr/include/openssl directory at all, and no libs either. Then I tried to compile src/secure/lib, but make there couldn't be completed too, because libcypher, which is compiled first, also was complaining about openssl library. I tried to compile src/secure/lib/libssl, it compiled successfully, but still it did not properly install all nesessary include files to /usr/include/openssl (only a few were installed), so I had to manually copy src/secure/lib/libssl/openssl/* to /usr/include/openssl/, after which I was able to compile the rest in src/secure/lib, the rest in src/secure and then, finally, src/lib. I think the reason that my initial installation didn't have openssl could be that I just forgot to toggle the appropriate flag in the sysinstall, but still, IMHO this shouldn't make update process that tricky. Generally, I think Makefiles could be constructed to reflect those dependencies, no ? And, why make install in the src/secure/lib/openssl only does this (first line wrapped so that mailer won't be confused with too long line): vel@bugz:/usr/src/secure/lib/libssl # make install install -c -o root -g wheel -m 444 /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl2.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl23.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl3.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl_locl.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/tls1.h /usr/include/openssl install -c -o root -g wheel -m 444 libssl.a /usr/lib install -c -o root -g wheel -m 444 libssl_p.a /usr/lib install -c -s -o root -g wheel -m 444 libssl.so.2 /usr/lib There a lot of other include files it should copy ... Or must I compile something else too before I can simply type "make" in the src/secure/lib which will work ? And if so, then again, why isn't Makefile there written to compile things in a proper order ? Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 6:17: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (unknown [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 0A8C537B403 for ; Mon, 6 Aug 2001 06:16:52 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 2922 invoked by uid 1000); 6 Aug 2001 13:15:40 -0000 Date: Mon, 6 Aug 2001 16:15:40 +0300 From: Peter Pentchev To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: libmp Message-ID: <20010806161540.G2110@ringworld.oblivion.bg> Mail-Followup-To: "Eugene L. Vorokov" , freebsd-hackers@freebsd.org References: <20010806153705.B2110@ringworld.oblivion.bg> <200108061718.f76HIoT59752@bugz.infotecs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108061718.f76HIoT59752@bugz.infotecs.ru>; from vel@bugz.infotecs.ru on Mon, Aug 06, 2001 at 05:18:49PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 06, 2001 at 05:18:49PM +0000, Eugene L. Vorokov wrote: > > > Hmm yes, it's there. But the snapshot I installed first doesn't > > > have it (why ?). When I installed it manually prior to compiling libs, > > > libmp compiles fine ... Btw, is there any guide of what is the proper > > > order of compiling things after cvsup ? > > > > Yep, the src/UPDATING file. > > > > What do you mean, the snapshot did not have it? Did you really > > CVSup 5.0-current on a machine running an earlier version, or did > > you install from a pre-built 5.0-current snapshot? Or are you referring > > to the CVSup snapshot - in what sense did it "not have it" - > > there was no src/crypto/openssl/ directory, or there was no > > src/secure/lib/libcrypto/ directory, or the libcrypto Makefile did > > not install the OpenSSL header files files under > > /usr/obj/.../src/i386/usr/include/openssl? > > > > How exactly are you trying to compile things? What did you do > > after the CVSup run? And.. what version are you updating from? > > I first installed the snapshot 5.0-20010618-CURRENT. Then I installed > cvsup and cvsup'ed src-all collection. When it was completed, I > tried to recompile the kernel, Strike one - the kernel needs *at least* config(8) (as you already know), and it might need updated parts of the build toolchain. This would certainly fail. Read src/UPDATING for the proper procedure. > but config was complaining that it's > version doesn't match the kernel version, so I compiled and installed > src/usr.sbin/config, then I configured and compiled kernel, it > compiled fine. Strike two - config(8) and the kernel still might need updated parts of the toolchain (e.g. new assembly syntax). You are lucky it worked. Read src/UPDATING. > Then I rebooted and tried to compile the userland things. > I was thinking that I must first install new include files, then > compile and install libs and then executables. Strike three - you are *almost* correct, but you ought to have first built the bootstrap tools, then used them to build a couple of other things, and only then move on to the include files. The 'buildworld' target takes care of all that in a very nice way. Read src/UPDATING :) > So I did make > and make install in the src/include directory and tried to do the > same in the src/lib, but it stopped on libmp. The src/include directory does not hold all include files at all. Some of them are spread out in library directories, some of them are even spread out in program directories. The 'buildworld' target takes care of all that in a very nice way. Read src/UPDATING :) > At that point I had > no /usr/include/openssl directory at all, and no libs either. Right. The src/include Makefile does not handle src/secure/libcrypto. The 'buildworld'... oh well ;) > Then > I tried to compile src/secure/lib, but make there couldn't be completed > too, because libcypher, which is compiled first, also was complaining > about openssl library. I tried to compile src/secure/lib/libssl, > it compiled successfully, but still it did not properly install all > nesessary include files to /usr/include/openssl (only a few were > installed), so I had to manually copy src/secure/lib/libssl/openssl/* > to /usr/include/openssl/, after which I was able to compile the rest > in src/secure/lib, the rest in src/secure and then, finally, src/lib. This sounds like you went to a *lot* of trouble just because you did not read the src/UPDATING file :) It is great that it finally worked, but.. it might have been easier :) > I think the reason that my initial installation didn't have openssl > could be that I just forgot to toggle the appropriate flag in the > sysinstall, but still, IMHO this shouldn't make update process that > tricky. Generally, I think Makefiles could be constructed to reflect > those dependencies, no ? They are; just not the Makefiles in the directories you looked at, and not in the way you tried to do it. The 'buildworld' and 'buildkernel' targets were specifically made to handle this kind of dependencies when updating from a much earlier version of FreeBSD. > And, why make install in the src/secure/lib/openssl only does this > (first line wrapped so that mailer won't be confused with too long > line): [snip make install output] > > There a lot of other include files it should copy ... As I mentioned in another email, src/secure/lib/openssl is not really relevant. src/secure/lib/libcrypto is much more important. > Or must I > compile something else too before I can simply type "make" in > the src/secure/lib which will work ? And if so, then again, why > isn't Makefile there written to compile things in a proper order ? The Makefile in that particular directory is written so as to be invoked by a higher-order Makefile that knows what dependencies ought to be satisfied, and what dependencies *have* already been satisfied. The Makefile in that particular directory is written so as to be able to be used when the rest of the tree is not really present, but only in a limited way. G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 6:35:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.kornet.net (unknown [211.48.62.162]) by hub.freebsd.org (Postfix) with ESMTP id F02AF37B401; Mon, 6 Aug 2001 06:32:52 -0700 (PDT) (envelope-from clubfriend@clubfriend.com) Received: from bown112 (211.38.171.177) by relay2.kornet.net; 6 Aug 2001 22:32:55 +0900 Message-ID: <006801c11e7b$fe8f4f20$b1ab26d3@kornet.net> Reply-To: "Youn, Roy" From: "Youn, Roy" To: =?ks_c_5601-1987?B?wK/H0MC7wdi68cfPtMK60LKy?= Subject: =?ks_c_5601-1987?B?W8irurhdwK/H0Mb4xbq96sDPISEhyK69x8fRwbawxyEhtbXA/MfP?= =?ks_c_5601-1987?B?vLy/5CEhISE=?= Date: Mon, 6 Aug 2001 22:30:35 +0900 Organization: =?ks_c_5601-1987?B?x8G3o7XlIMCvx9C/+A==?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C11EC7.693216A0" 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_0063_01C11EC7.693216A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ICAgICAgICAgICANCg0KDQogICAgICAgICAgICC+yLPnx8+8vL/kIMfBt6O15SDAr8fQv/ggwNS0 z7TZLg0KICAgICAgICAgICAgursguN7Az8C6IMiruri43sDPwNS0z7TZLiDH47b0vvjAzCC43sDP wLsgurizu7XluK6w1CC1yCDBob+hILTrx9ggwcu828fVtM+02S4gDQoNCiAgICAgICAgICAgICog sc3Hz8DHIGVtYWlsIMGkuri0wiDIqMbkwMzB9iC51yCw1L3Dxse/obytIML8wbbHz7+0vcC0z7TZ Lg0KDQoNCiAgICAgICAgICAgIL+1vu6woSC09SDAzLvzwLoguaux4rChIL7GtNEgx8q89sD7wM4g v+S80rfOILTZsKG/wLTCIMDMIL3DtOu/oSDFq7W3IL7ItenAzLDttbUgx9i/3L+svPa/zSDAr7e0 ILnos7a/qcfgse7B9iC02bPgv8MgvPYgwNa0wrHiyLiwoSDA1r7uvK0gvNKwsyDH1bTPtNkuDQog ICAgICAgICAgICCx17DNtbUgwaTF67+1vu64piC56L/vILz2IMDWtMIgv7WxuSC3sbT4wMcgTE9O RE9OIEVOR0xJU0ggU0NIT09MIL+hvK0gwNS0z7TZLg0KDQogICAgICAgICAgICC6zrTjIL74tMIg sKGw3cC4t84gw+K538fPsO0gx/bB9r+hvK0gvsa4o7nZwMzGrsfPuOkgw+a60Mj3ILv9yLC68bim ILn6vPYgwNa9wLTPtNkuILbHx9Egv6y89rChILOhs6q46SCwobHuv+4gx8G2+726LCDAzMXCuK4g te4gv6m3ryDAr7e0s6q287fOILnos7a/qcfgwLsgtrCzryC89iDA1r3AtM+02S4NCg0KDQogICAg ICAgICAgICAgICAgICDH4LvnwM/BpCA0wvcgOS8zIDogMjAguO0gwaS/+CAoMrjtv6nArykgDQog ICAgICAgICAgICAgICAgICAoMjAwMbPiKSA1wvcgOS8yNCA6IDIwILjtIMGkv/ggIA0KICAgICAg ICAgICAgICAgICAgICA2wvcgMTAvMTkgOiAxNSC47SDBpL/4ICi4trCoKSANCiAgICAgICAgICAg ICAgICAgICAgN8L3IDExLzQgOiAxNSC47SDBpL/4IA0KDQogICAgICAgICAgICDC/LChuvEgOiC/ rLz2IDaws7/5seLB2CAzODAguLi/+CAvIL+svPYgMbPiILHiwdggNDQwILi4v/ggKMSrteUgsOHB piCwobTJKSAoKiogv6y89rHisKMgv6zA5bChtMkpDQogICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICDC/LChuvEgxvfH1LO7v6ogOiC/1bq5IMfXsPixxyAoNrCzv/mwoyks ILz2vve34SDA/L7XLCA0wdYgvPe52rrxICgywM4xvccpLCC89rzTt+EsIMPiud/A/CC80r7nsbPA sCwgseKz5CC6ubTrLCC/qcfgwNogurjH6Cwgx/bB9rChwMy15SAosPjH17nMxsMsILz3vNIsIMfQ sbMsIL7GuKO52cDMxq4pIA0KICAgICAgICAgICAgKrvzseIgsd2+18C6IMfQuvEgwPy+1yC51yDA z8O8IMb3x9TAzLbzILT1IMDMu/PAxyDD37ChILrxv+vAuiC++MC4uOcgv7m78yC7/ciwuvG/6yAo vPe9xLrxLCCxs8XrLCC/67W3KcC6IL/5IDcwuLi/+CC8scC4t84gvsa4o7nZwMzGriC89sDUwLi3 ziDD5rTnILChtMnH1bTPtNkuIA0KICAgICAgICAgICAgx/bB9iC+xrijudnAzMauIDogxLO8xSwg veG68Swgv6nH4LvnILChwMy15SC51yC757mrwfcsILzux84gvsa4o7nZwMzGriwgvcS05yC6uMG2 te4gDQogICAgICAgICAgICDH9sH2IL7GuKO52cDMxq4gvPbA1CA6IL3DsKO05yDD1sD6IDcsMDAw v/h+MTAsMDAwv/ggICAxwM8gNb3DsKMsIMHWIDXAzyCx2b3DIC0tLSAxsLO/+SDD1sD6ILz2wNQg NzC4uL/4IH4gMTAwuLi/+CANCg0KDQogICAgICAgICAgICDB9r/4IMDasN0gOiAxOLy8IMDMu/Mg s7IsILPgILSpsbizqiCwobTJICi0qbG4s6ogwK/H0LrxwNogMTAwJSC53r7GteW4sikNCg0KICAg ICAgICAgICAgwNq8vMfRILvnu/PAuiDIqMbkwMzB9iC55rmuwMyzqiC6u7vnt84gv6y29CDB1r3D uOkgw9a8scC7ILTZx9ggtbW/zSC15biusNq9wLTPtNkuDQogICAgICAgICAgICBodHRwOi8vd3d3 LmNsdWJmcmllbmQuY29tIC8gx8G3o7XlIMCvx9C/+CAwMzEtMzk2LTc5MDUvNg0KDQogICAgICAg ICAgICC9xcO7wLsgv/jHz73DtMK60MC6IMDMsPfAuyDF68fPv6kgvcXDu7ytuKYgud+828fPv6kg wda9w7HiILnZtvi0z7TZLg0KICAgICAgICAgICAgwbax4iC9xcO7wNq0wiC897zSILyxxcPAzLOq IL7GuKO52cDMxq4gvNKws73Dxq/A/MDMIMHWvu4gwf20z7TZLiANCg0KICAgICAgICAgICAgKrq7 IMCvx9C/+MC6IEJDIMSrteW75yC/tbG5v6y89iC788ewIMf5t8K+98O8IMDUtM+02S4NCg0KICAg ICAgICAgICANCiAgICAgDQoNCg== ------=_NextPart_000_0063_01C11EC7.693216A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFRBQkxF IGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD01MDAgYm9yZGVyPTE+DQogIDxUQk9E WT4NCiAgPFRSPg0KICAgIDxURD4NCiAgICAgIDxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRk aW5nPTAgd2lkdGg9NTAwIGJvcmRlcj0wPg0KICAgICAgICA8VEJPRFk+DQogICAgICAgIDxUUj4N CiAgICAgICAgICA8VEQgd2lkdGg9NTAwIGhlaWdodD0yNTA+DQogICAgICAgICAgICA8T0JKRUNU IA0KICAgICAgICAgICAgY29kZUJhc2U9aHR0cDovL2Rvd25sb2FkLm1hY3JvbWVkaWEuY29tL3B1 Yi9zaG9ja3dhdmUvY2Ficy9mbGFzaC9zd2ZsYXNoLmNhYiN2ZXJzaW9uPTUsMCwwLDAgDQogICAg ICAgICAgICBjbGFzc2lkPWNsc2lkOkQyN0NEQjZFLUFFNkQtMTFjZi05NkI4LTQ0NDU1MzU0MDAw MCB3aWR0aD01MDAgDQogICAgICAgICAgICBoZWlnaHQ9MjUwPjxQQVJBTSBOQU1FPSJfY3giIFZB TFVFPSIxMzIyOSI+PFBBUkFNIE5BTUU9Il9jeSIgVkFMVUU9IjY2MTUiPjxQQVJBTSBOQU1FPSJN b3ZpZSIgVkFMVUU9Imh0dHA6Ly9jbHViZnJpZW5kLmNvbS+xpLDtLnN3ZiI+PFBBUkFNIE5BTUU9 IlNyYyIgVkFMVUU9Imh0dHA6Ly9jbHViZnJpZW5kLmNvbS+xpLDtLnN3ZiI+PFBBUkFNIE5BTUU9 IldNb2RlIiBWQUxVRT0iV2luZG93Ij48UEFSQU0gTkFNRT0iUGxheSIgVkFMVUU9Ii0xIj48UEFS QU0gTkFNRT0iTG9vcCIgVkFMVUU9Ii0xIj48UEFSQU0gTkFNRT0iUXVhbGl0eSIgVkFMVUU9Ikhp Z2giPjxQQVJBTSBOQU1FPSJTQWxpZ24iIFZBTFVFPSIiPjxQQVJBTSBOQU1FPSJNZW51IiBWQUxV RT0iLTEiPjxQQVJBTSBOQU1FPSJCYXNlIiBWQUxVRT0iIj48UEFSQU0gTkFNRT0iU2NhbGUiIFZB TFVFPSJTaG93QWxsIj48UEFSQU0gTkFNRT0iRGV2aWNlRm9udCIgVkFMVUU9IjAiPjxQQVJBTSBO QU1FPSJFbWJlZE1vdmllIiBWQUxVRT0iMCI+PFBBUkFNIE5BTUU9IkJHQ29sb3IiIFZBTFVFPSIi PjxQQVJBTSBOQU1FPSJTV1JlbW90ZSIgVkFMVUU9IiI+PFBBUkFNIE5BTUU9IlN0YWNraW5nIiBW QUxVRT0iYmVsb3ciPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICA8ZW1iZWQg ICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vY2x1YmZyaWVuZC5jb20vsaSw7S5z d2YiIA0KICAgICAgICAgICAgcXVhbGl0eT1oaWdoICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgcGx1Z2luc3BhZ2U9Imh0dHA6Ly93d3cubWFjcm9tZWRpYS5jb20vc2hvY2t3 YXZlL2Rvd25sb2FkL2luZGV4LmNnaT9QMV9Qcm9kX1ZlcnNpb249U2hvY2t3YXZlRmxhc2giIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0iYXBwbGljYXRpb24veC1z aG9ja3dhdmUtZmxhc2giIA0KICAgICAgICAgICAgd2lkdGg9IjUwMCIgICAgICAgICAgICAgaGVp Z2h0PSIyNTAiPiAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICA8L2VtYmVk PiAgICAgICAgICAgICAgICAgICAgICAgPC9PQkpFQ1Q+PC9URD48L1RSPg0KICAgICAgICA8VFI+ DQogICAgICAgICAgPFREPg0KICAgICAgICAgICAgPFA+Jm5ic3A7PC9QPg0KICAgICAgICAgICAg PFA+PEZPTlQgc2l6ZT0tMT6+yLPnx8+8vL/kIMfBt6O15SDAr8fQv/ggwNS0z7TZLjxCUj66uyC4 3sDPwLogyKu6uLjewM/A1LTPtNkuIMfjtvS++MDMILjewM/AuyC6uLO7teW4rrDUIA0KICAgICAg ICAgICAgtcggwaG/oSC068fYIMHLvNvH1bTPtNkuIDwvRk9OVD48L1A+DQogICAgICAgICAgICA8 UD48Rk9OVCBzaXplPS0xPiogsc3Hz8DHIGVtYWlsIMGkuri0wiDIqMbkwMzB9iC51yCw1L3Dxse/ obytIML8wbbHz7+0vcC0z7TZLjwvRk9OVD48L1A+DQogICAgICAgICAgICA8UD48Rk9OVCBzaXpl PS0xPjxCUj6/tb7usKEgtPUgwMy788C6ILmrseKwoSC+xrTRIMfKvPbA+8DOIL/kvNK3ziC02bCh v8C0wiDAzCC9w7Trv6Egxau1tyC+yLXpwMyw7bW1IA0KICAgICAgICAgICAgPEI+PEZPTlQgY29s b3I9IzAwMDA4MD7H2L/cv6y89r/NIMCvt7Qgueiztr+px+A8L0ZPTlQ+PC9CPrHuwfYgtNmz4L/D ILz2IMDWtMKx4si4sKEgwNa+7rytILzSsLMgDQogICAgICAgICAgICDH1bTPtNkuPEJSPrHXsM21 tSDBpMXrv7W+7rimILnov+8gvPYgwNa0wiC/tbG5ILextPjAxyA8Qj48Rk9OVCBjb2xvcj0jMDAw MDgwPkxPTkRPTiANCiAgICAgICAgICAgIEVOR0xJU0ggU0NIT09MPC9GT05UPjwvQj48Rk9OVCBj b2xvcj0jMDAwMDgwPiA8L0ZPTlQ+v6G8rSANCiAgICAgICAgICAgIMDUtM+02S48L0ZPTlQ+PC9Q Pg0KICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT66zrTjIL74tMIgsKGw3cC4t84gw+K538fP sO0gx/bB9r+hvK0gvsa4o7nZwMzGrsfPuOkgw+a60Mj3ILv9yLC68bimILn6vPYgwNa9wLTPtNku ILbHx9EgDQogICAgICAgICAgICC/rLz2sKEgs6GzqrjpILChse6/7iDHwbb7vbosIMDMxcK4riC1 7iC/qbevIMCvt7Szqrbzt84gueiztr+px+DAuyC2sLOvILz2IMDWvcC0z7TZLjwvRk9OVD48Rk9O VCANCiAgICAgICAgICAgIHNpemU9LTE+PEJSPjwvRk9OVD48L1A+DQogICAgICAgICAgICA8VEFC TEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSI4MCUiIGJvcmRlcj0wPg0KICAg ICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgICAgICA8 VEQgd2lkdGg9IjI3JSI+PEZPTlQgc2l6ZT0tMT7H4LvnwM/BpDwvRk9OVD48L1REPg0KICAgICAg ICAgICAgICAgIDxURCB3aWR0aD0iMjIlIj48Rk9OVCBzaXplPS0xPjTC9yA5LzMgOjwvRk9OVD48 L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9OVCBzaXplPS0xPjIwILjt IMGkv/ggKDK47b+pwK8pPC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgICAgICAgPFRSPg0KICAg ICAgICAgICAgICAgIDxURCB3aWR0aD0iMjclIj48Rk9OVCBzaXplPS0xPigyMDAxs+IpPC9GT05U PjwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSIyMiUiPjxGT05UIHNpemU9LTE+NcL3 IDkvMjQgOjwvRk9OVD48L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9O VCBzaXplPS0xPjIwILjtIMGkv/ggPC9GT05UPjwvVEQ+PC9UUj4NCiAgICAgICAgICAgICAgPFRS Pg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iMjclIj4mbmJzcDs8L1REPg0KICAgICAgICAg ICAgICAgIDxURCB3aWR0aD0iMjIlIj48Rk9OVCBzaXplPS0xPjbC9yAxMC8xOSA6PC9GT05UPjwv VEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI1MSUiPjxGT05UIHNpemU9LTE+MTUguO0g waS/+CAouLawqCk8L0ZPTlQ+PC9URD48L1RSPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAg ICAgICAgICAgPFREIHdpZHRoPSIyNyUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFRE IHdpZHRoPSIyMiUiPjxGT05UIHNpemU9LTE+N8L3IDExLzQgOjwvRk9OVD48L1REPg0KICAgICAg ICAgICAgICAgIDxURCB3aWR0aD0iNTElIj48Rk9OVCBzaXplPS0xPjE1ILjtIA0KICAgICAgICAg ICAgwaS/+DwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxGT05UIHNpemU9LTE+PEJS PsL8sKG68SA6IL+svPYgPEZPTlQgDQogICAgICAgICAgICBjb2xvcj0jZmYwMDAwIHNpemU9Mz48 Qj42sLO/+bHiwdggMzgwILi4v/g8L0I+PC9GT05UPiAvIL+svPYgPEZPTlQgDQogICAgICAgICAg ICBzaXplPTM+PEI+PEZPTlQgY29sb3I9I2ZmMDAwMD4xs+IgseLB2CA0NDAguLi/+DwvRk9OVD48 L0I+IDwvRk9OVD4oxKu15SCw4cGmIA0KICAgICAgICAgICAgsKG0yTxGT05UIGNvbG9yPSMwMDAw ODA+KTwvRk9OVD4gKCoqIL+svPax4rCjIL+swOWwobTJKTxCUj48L0ZPTlQ+DQogICAgICAgICAg ICA8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9 MD4NCiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAg ICAgICAgPFREIHdpZHRoPSIxOCUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdp ZHRoPSI4MiUiPiZuYnNwOzwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQogICAgICAgICAgICA8 VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4N CiAgICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAgICAg ICAgPFREIHZBbGlnbj10b3Agd2lkdGg9IjIyJSI+PEZPTlQgc2l6ZT0tMT7C/LChuvEgxvfH1LO7 v6ogOjwvRk9OVD48L1REPg0KICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iNzglIj48Rk9OVCBz aXplPS0xPr/Vurkgx9ew+LHHICg2sLO/+bCjKSwgPEI+PEZPTlQgDQogICAgICAgICAgICAgICAg ICBjb2xvcj0jMDAwMDgwPrz2vve34SDA/L7XPC9GT05UPjwvQj4sIDTB1iC897nauvEgKDLAzjG9 xyksILz2vNO34Swgw+K538D8ILzSvuexs8CwLCANCiAgICAgICAgICAgICAgICAgILHis+Qgurm0 6ywgv6nH4MDaILq4x+gsIMf2wfawocDMteUgKLD4x9e5zMbDLCC897zSLCDH0LGzLCANCiAgICAg ICAgICAgIL7GuKO52cDMxq4pPC9GT05UPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEZPTlQg c2l6ZT0tMT4qu/Ox4iCx3b7XwLogx9C68SDA/L7XILnXIA0KICAgICAgICAgICAgwM/DvCDG98fU wMy28yA8Rk9OVCBjb2xvcj0jMDAwMDgwPjxCPrT1IMDMu/PAxyDD37ChILrxv+vAuiC++MC4uOc8 L0I+PC9GT05UPiC/ubvzILv9yLC68b/rIA0KICAgICAgICAgICAgKLz3vcS68SwgsbPF6ywgv+u1 tynAuiC/+SA3MLi4v/ggvLHAuLfOIL7GuKO52cDMxq4gvPbA1MC4t84gw+a05yCwobTJx9W0z7TZ LiA8L0ZPTlQ+DQogICAgICAgICAgICA8UD48Rk9OVCBzaXplPS0xPsf2wfYgvsa4o7nZwMzGriA6 IMSzvMUsIL3huvEsIL+px+C75yCwocDMteUgudcgu+e5q8H3LCC87sfOIL7GuKO52cDMxq4sIL3E tOcgurjBtrXuIA0KICAgICAgICAgICAgPEJSPsf2wfYgvsa4o7nZwMzGriC89sDUIDogvcOwo7Tn IMPWwPogNywwMDC/+H4xMCwwMDC/+CA8L0ZPTlQ+DQogICAgICAgICAgICA8VEFCTEUgY2VsbFNw YWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4NCiAgICAgICAgICAg ICAgPFRCT0RZPg0KICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAgICAgICAgPFREIHdpZHRo PSIyNyUiPiZuYnNwOzwvVEQ+DQogICAgICAgICAgICAgICAgPFREIHdpZHRoPSI3MyUiPjxGT05U IHNpemU9LTE+McDPIDW9w7CjLCDB1iA1wM8gsdm9wyAtLS0gMbCzv/kgw9bA+iC89sDUIA0KICAg ICAgICAgICAgICAgICAgNzC4uL/4IH4gMTAwuLi/+DwvRk9OVD48L1REPjwvVFI+PC9UQk9EWT48 L1RBQkxFPg0KICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT7B9r/4IMDasN0gOiA8Qj48Rk9O VCBjb2xvcj0jMDAwMDgwPjE4vLwgwMy78yCzsiwgs+AgtKmxuLOqIA0KICAgICAgICAgICAgsKG0 yTwvRk9OVD48L0I+ICi0qbG4s6ogwK/H0LrxwNogMTAwJSC53r7GteW4sik8L0ZPTlQ+PC9QPg0K ICAgICAgICAgICAgPFA+PEZPTlQgc2l6ZT0tMT7A2ry8x9Egu+e788C6IMioxuTAzMH2ILnmua7A zLOqILq7u+e3ziC/rLb0IMHWvcO46SDD1ryxwLsgtNnH2CC1tb/NIA0KICAgICAgICAgICAgteW4 rrDavcC0z7TZLjxCUj48QSBocmVmPSJodHRwOi8vY2x1YmZyaWVuZC5jb20iPmh0dHA6Ly93d3cu Y2x1YmZyaWVuZC5jb20gDQogICAgICAgICAgICA8L0E+LyDHwbejteUgwK/H0L/4IDAzMS0zOTYt NzkwNS82PC9GT05UPjwvUD4NCiAgICAgICAgICAgIDxQPjxGT05UIHNpemU9LTE+PEEgDQogICAg ICAgICAgICBocmVmPSJodHRwOi8vY2x1YmZyaWVuZC5jb20vc3VibWl0LWZyYW1lLmh0bWwiPjxC PjxGT05UIA0KICAgICAgICAgICAgY29sb3I9IzAwMDA4MD69xcO7wLsgv/jHz73DtMK60MC6IMDM sPfAuyDF68fPv6kgvcXDu7ytuKYgud+82zwvRk9OVD48L0I+PC9BPsfPv6kgwda9w7HiIA0KICAg ICAgICAgICAgudm2+LTPtNkuPEJSPsG2seIgvcXDu8DatMIgvPe80iC8scXDwMyzqiC+xrijudnA zMauILzSsLO9w8avwPzAzCDB1r7uIMH9tM+02S4gPC9GT05UPjwvUD4NCiAgICAgICAgICAgIDxQ PjxGT05UIHNpemU9LTE+PEI+PEZPTlQgY29sb3I9IzAwMDA4MD4qursgwK/H0L/4wLogQkMgxKu1 5bvnIL+1sbm/rLz2ILvzx7Agx/m3wr73w7wgDQogICAgICAgICAgICDA1LTPtNkuPC9GT05UPjwv Qj48L0ZPTlQ+PC9QPg0KICAgICAgICAgICAgPFA+PC9QPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFC TEU+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_0063_01C11EC7.693216A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 7:17:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 394F637B405 for ; Mon, 6 Aug 2001 07:17:46 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.5/8.11.4) id f76IYBO64264 for freebsd-hackers@freebsd.org; Mon, 6 Aug 2001 18:34:11 GMT (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108061834.f76IYBO64264@bugz.infotecs.ru> Subject: pam_wheel To: freebsd-hackers@freebsd.org Date: Mon, 6 Aug 2001 18:34:11 +0000 (GMT) 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 Hello, pam_wheel authentication module seems to be broken in -current. Look at this (from src/lib/libpam/modules/pam_wheel): PAM_EXTERN int pam_sm_authenticate(pam_handle_t * pamh, int flags, int argc, const char **argv) { struct options options; struct passwd *pwd; struct group *grp; int retval; const char *user; char *use_group; pam_std_option(&options, other_options, argc, argv); PAM_LOG("Options processed"); if (pam_test_option(&options, PAM_OPT_AUTH_AS_SELF, NULL)) pwd = getpwnam(getlogin()); else { retval = pam_get_user(pamh, &user, NULL); if (retval != PAM_SUCCESS) PAM_RETURN(retval); pwd = getpwnam(user); } PAM_LOG("Got user: %s", user); /* Ignore if already uid 0 */ if (pwd->pw_uid) PAM_RETURN(PAM_IGNORE); PAM_LOG("Not superuser"); This piece obviously has at least two errors. First, if PAM_OPT_AUTH_AS_SELF is true, then value of user is undefined. It should probably log pwd->pw_name instead. Second, check for root must of course be reversed and become if (!pwd->pw_uid). The way it works now, it always returns PAM_IGNORE for all non-root users, which causes in allowing "su" for anyone who knows root password. Or am I missing something again ? 8=) Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 8:10:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 7476D37B401; Mon, 6 Aug 2001 08:10:50 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=65c9a564a79b1c61e4536a68eeb31360) by softweyr.com with esmtp (Exim 3.16 #1) id 15Tm9Q-0000ob-00; Mon, 06 Aug 2001 09:18:40 -0600 Message-ID: <3B6EB550.FEED14E7@softweyr.com> Date: Mon, 06 Aug 2001 09:18:40 -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: Randy Bush Cc: Leo Bicknell , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel References: <20010804215529.C7176@cicely20.cicely.de> <32301.996956619@verdi.nethelp.no> <20010805002233.A7991@cicely20.cicely.de> <20010804184045.A87444@ussenterprise.ufp.org> <200108050027.f750RkG77073@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 Randy Bush wrote: > > > All of the current designs used in the core, and many of the edge > > designs as well keep the "full table" (distilled to the minimum > > amount of information to forward a packet) available to the hardware > > forwarding engine. This includes Cisco's GSR line, and Junipers > > M-series routers. While working differently, Cisco's 7200's and > > 3600's also do the "full table thing". > > to be clear. they keep the *forwarding* table on card/in-cache, not the ^^^^^^^^^^^^^^^^^^ Which is, essentially, a route cache. The difference is a big router (really a switch these days) has a number of processors on the network interface cards to process the forwarding table. -- "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 Mon Aug 6 8:26:18 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 5620637B401; Mon, 6 Aug 2001 08:26:11 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f76FQ7X06801; Mon, 6 Aug 2001 11:26:07 -0400 (EDT) (envelope-from bicknell) Date: Mon, 6 Aug 2001 11:26:07 -0400 From: Leo Bicknell To: Wes Peters Cc: Randy Bush , Leo Bicknell , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: 303,000 routes in kernel Message-ID: <20010806112607.A6191@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , Wes Peters , Randy Bush , Leo Bicknell , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <20010804215529.C7176@cicely20.cicely.de> <32301.996956619@verdi.nethelp.no> <20010805002233.A7991@cicely20.cicely.de> <20010804184045.A87444@ussenterprise.ufp.org> <200108050027.f750RkG77073@earth.backplane.com> <3B6EB550.FEED14E7@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6EB550.FEED14E7@softweyr.com>; from wes@softweyr.com on Mon, Aug 06, 2001 at 09:18:40AM -0600 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 Mon, Aug 06, 2001 at 09:18:40AM -0600, Wes Peters wrote: > > to be clear. they keep the *forwarding* table on card/in-cache, not the > ^^^^^^^^^^^^^^^^^^ > Which is, essentially, a route cache. Per the dictionary definition of cache, perhaps, but 'cache' means something very different to those of us in router land. A cache based router (think 75xx Cisco _WITHOUT_ CEF), when a packet comes in for a route that has not been used the cache misses, the packet is punted to a general purpose CPU, the lookup done, and a cache entry installed on a linecard. Cache memories were limited, and were as such aged. This scheme had a number of problems: 1) High first packet penality of a flow. 2) The number of flows could exceed available cache memory. 3) The aging process hammered the box. 4) The aging process often removed active flows, causing a first packet penality mid-flow, sometimes causing TCP events (eg backoff). This became a larger problem day by day, as a larger percentage of the routing entries were sitting in the cache. So, router vendors went with cache-free designs. In a cache free design there is the RIB - Routing Information Base which contains routes the way routing protocols see them (eg, destination foo is in bgp which has a next hop in ospf which has a next hop out a connected interface), there are many levels of indirection there so recalculations can be done. At various checkpoints (typically after each protocol does a recalculation) the router builds the FIB - Forwarding Information base. This takes all the levels of indirection, and boils them down to where the packet goes (desination to connected interface). This table as such is smaller, and only ever requires a single lookup to know where to send a packet. The new routing designs then use the FIB (distributed to the linecards on the Cisco GSR and 7500 with CEF, kept on a central forwarding engine on the Juniper M-series). The important thing to note (which makes it not a cache in my book) is that it is th full table, need it or not, there can be no "miss" for an active route. Back to the original topic, small UDP packets from a DNS server. In the caching routers, each packet would generate a cache entry, which 95% of the time would never be used again before it was aged. The adding and removing of entries hammered the routers. Newer routers always have all entries in the FIB, so there is no penality for throwing packets at the box that go in different directions, or that go once and are never seen from again. So, if you want to call it a cache, that's fine. If you say that to a router jockey, you're going to give them the impression you're talking about the first setup though, which I don't think is what you want. -- 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 Mon Aug 6 9:22:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout3-0 (mailout3-0.nyroc.rr.com [24.92.226.118]) by hub.freebsd.org (Postfix) with ESMTP id 646A537B403 for ; Mon, 6 Aug 2001 09:22:08 -0700 (PDT) (envelope-from assem@twcny.rr.com) Received: from twcny.rr.com (syr-24-92-246-130.twcny.rr.com [24.92.246.130]) by mailout3-0 (8.11.2/RoadRunner 1.03) with ESMTP id f76GKtW26549 for ; Mon, 6 Aug 2001 12:20:56 -0400 (EDT) Message-ID: <3B6EC2E5.CF2077FC@twcny.rr.com> Date: Mon, 06 Aug 2001 12:16:37 -0400 From: Assem Salama X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: detach 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 have a question. I'm trying to make a module for a PCI card. My problem is my 'detach' function never get's called when I unload the module. Al my other functions get called correctly. Here is my source: #define DRIVERNAME "ide_mod" #ifdef DEBUG #define PRINTD(STR) uprintf("%s: %s",DRIVERNAME, STR); #else #define PRINTD(STR) #endif static int ide_mod_detach(device_t dev) { PRINTD("Inside detach ... \n"); return 0; } static device_method_t ide_mod_methods[] = { /* device methods */ DEVMETHOD(device_probe, ide_mod_probe), DEVMETHOD(device_attach, ide_mod_attach), DEVMETHOD(device_detach, ide_mod_detach), {0, 0} }; static driver_t ide_mod_driver = { "ide_mod", ide_mod_methods, sizeof(ide_mod_softc), }; static devclass_t ide_mod_devclas; /* all our macros */ DRIVER_MODULE(ide_mod, atapci, ide_mod_driver, ide_mod_devclas, 0, 0); Thanks, Assem Salama To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 10:48:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dopey.corp.expertcity.com (host1.expertcity.rangefire.net [216.64.159.146]) by hub.freebsd.org (Postfix) with ESMTP id F2D4A37B403 for ; Mon, 6 Aug 2001 10:48:18 -0700 (PDT) (envelope-from jeff@expertcity.com) Received: by dopey.corp.expertcity.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 10:49:06 -0700 Message-ID: <0307F3737A2AD511A42200D0B7A071919A402F@dopey.corp.expertcity.com> From: Jeff Behl To: "'freebsd-hackers@freebsd.org'" Subject: timing question Date: Mon, 6 Aug 2001 10:49:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 please excuse and direct me to the right place if this isn't the appropriate place to post this sort of question.... we're looking into moving to freebsd (yea!), but found the following problem. It seems that the shortest amount of time the below code will sleep for is 20 seconds! any call to nanosleep for 5,10, etc miliseconds returns a 20 ms delay. are we doing something wrong? thanks jeff typedef int64_t INT64; INT64 start = getMilliseconds(); struct timespec tspec; tspec.tv_sec = 0; tspec.tv_nsec = 5*(1000*1000); // millisconds -> nanoseconds nanosleep(&tspec, NULL); INT64 end = getMilliseconds(); INT64 elapsed = end - start; //return time in microseconds. INT64 getMilliseconds() { struct timeval tp; gettimeofday( &tp, NULL ); return (INT64)tp.tv_sec * 1000 + ((INT64)tp.tv_usec)/1000; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 10:52:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 976C737B409 for ; Mon, 6 Aug 2001 10:52:16 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f76Ht5i01556; Mon, 6 Aug 2001 10:55:06 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108061755.f76Ht5i01556@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Assem Salama Cc: freebsd-hackers@freebsd.org Subject: Re: detach In-reply-to: Your message of "Mon, 06 Aug 2001 12:16:37 EDT." <3B6EC2E5.CF2077FC@twcny.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 10:55:05 -0700 From: Mike Smith Sender: owner-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 have a question. I'm trying to make a module for a PCI card. My > problem is my 'detach' function never get's called when I unload the > module. Al my other functions get called correctly. Here is my source: Detach != unload. The detach method is called by your parent to kick you out. If you want to be notified when your module is unloaded, you need a module event handler which finds all your instances and detaches them itself. Use devclass_find_devices() to locate your instances, and then run across all the detach routines. If any of them return nonzero, you should refuse to unload. This is because there isn't a 1:1 correspondence between a loaded module and a driver instance. > > #define DRIVERNAME "ide_mod" > > #ifdef DEBUG > #define PRINTD(STR) uprintf("%s: %s",DRIVERNAME, > STR); > #else > #define PRINTD(STR) > #endif > > static int ide_mod_detach(device_t dev) > { > PRINTD("Inside detach ... \n"); > return 0; > } > > > static device_method_t ide_mod_methods[] = > { > /* device methods */ > DEVMETHOD(device_probe, ide_mod_probe), > DEVMETHOD(device_attach, ide_mod_attach), > DEVMETHOD(device_detach, ide_mod_detach), > {0, 0} > }; > > static driver_t ide_mod_driver = { > "ide_mod", > ide_mod_methods, > sizeof(ide_mod_softc), > }; > > static devclass_t ide_mod_devclas; > > /* all our macros */ > DRIVER_MODULE(ide_mod, atapci, ide_mod_driver, ide_mod_devclas, 0, 0); > > > Thanks, > Assem Salama > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 11: 2:19 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 180AC37B403; Mon, 6 Aug 2001 11:02:08 -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 NAA66198; Mon, 6 Aug 2001 13:12:12 -0700 (PDT) Date: Mon, 6 Aug 2001 13:12:11 -0700 (PDT) From: Julian Elischer To: Mike Smith Cc: Assem Salama , freebsd-hackers@freebsd.org Subject: Re: detach In-Reply-To: <200108061755.f76Ht5i01556@mass.dis.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 if you can write a little sample code I'll put it in the sample driver. On Mon, 6 Aug 2001, Mike Smith wrote: > > Hello, > > I have a question. I'm trying to make a module for a PCI card. My > > problem is my 'detach' function never get's called when I unload the > > module. Al my other functions get called correctly. Here is my source: > > Detach != unload. > > The detach method is called by your parent to kick you out. If you want > to be notified when your module is unloaded, you need a module event > handler which finds all your instances and detaches them itself. > > Use devclass_find_devices() to locate your instances, and then run across > all the detach routines. If any of them return nonzero, you should > refuse to unload. > > This is because there isn't a 1:1 correspondence between a loaded module > and a driver instance. > > > > > #define DRIVERNAME "ide_mod" > > > > #ifdef DEBUG > > #define PRINTD(STR) uprintf("%s: %s",DRIVERNAME, > > STR); > > #else > > #define PRINTD(STR) > > #endif > > > > static int ide_mod_detach(device_t dev) > > { > > PRINTD("Inside detach ... \n"); > > return 0; > > } > > > > > > static device_method_t ide_mod_methods[] = > > { > > /* device methods */ > > DEVMETHOD(device_probe, ide_mod_probe), > > DEVMETHOD(device_attach, ide_mod_attach), > > DEVMETHOD(device_detach, ide_mod_detach), > > {0, 0} > > }; > > > > static driver_t ide_mod_driver = { > > "ide_mod", > > ide_mod_methods, > > sizeof(ide_mod_softc), > > }; > > > > static devclass_t ide_mod_devclas; > > > > /* all our macros */ > > DRIVER_MODULE(ide_mod, atapci, ide_mod_driver, ide_mod_devclas, 0, 0); > > > > > > Thanks, > > Assem Salama > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E > > > > 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 6 11:30:40 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 800A237B403; Mon, 6 Aug 2001 11:30:37 -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 f76IUOx02739; Mon, 6 Aug 2001 20:30:25 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f76IUQu14956; Mon, 6 Aug 2001 20:30:26 +0200 (CEST) Date: Mon, 6 Aug 2001 20:30:25 +0200 From: Bernd Walter To: Julian Elischer Cc: Mike Smith , Assem Salama , freebsd-hackers@FreeBSD.ORG Subject: Re: detach Message-ID: <20010806203025.B14445@cicely20.cicely.de> References: <200108061755.f76Ht5i01556@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Mon, Aug 06, 2001 at 01:12:11PM -0700 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 Mon, Aug 06, 2001 at 01:12:11PM -0700, Julian Elischer wrote: > if you can write a little sample code I'll put it in the sample driver. Isn't it already in /usr/share/examples/kld? E.g /usr/share/examples/kld/cdev/module/cdevmod.c -- 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 Mon Aug 6 11:42:16 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 343CD37B401; Mon, 6 Aug 2001 11:42: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 NAA66334; Mon, 6 Aug 2001 13:57:46 -0700 (PDT) Date: Mon, 6 Aug 2001 13:57:46 -0700 (PDT) From: Julian Elischer To: Bernd Walter Cc: Mike Smith , Assem Salama , freebsd-hackers@FreeBSD.ORG Subject: Re: detach In-Reply-To: <20010806203025.B14445@cicely20.cicely.de> 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 no, that doesn't do what mike said.. On Mon, 6 Aug 2001, Bernd Walter wrote: > On Mon, Aug 06, 2001 at 01:12:11PM -0700, Julian Elischer wrote: > > if you can write a little sample code I'll put it in the sample driver. > > Isn't it already in /usr/share/examples/kld? > E.g /usr/share/examples/kld/cdev/module/cdevmod.c > > -- > 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 Mon Aug 6 12:50: 7 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 3AD4137B403 for ; Mon, 6 Aug 2001 12:50:05 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 242B481D05; Mon, 6 Aug 2001 14:49:55 -0500 (CDT) Date: Mon, 6 Aug 2001 14:49:55 -0500 From: Alfred Perlstein To: Jeff Behl Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: timing question Message-ID: <20010806144955.O85642@elvis.mu.org> References: <0307F3737A2AD511A42200D0B7A071919A402F@dopey.corp.expertcity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0307F3737A2AD511A42200D0B7A071919A402F@dopey.corp.expertcity.com>; from jeff@expertcity.com on Mon, Aug 06, 2001 at 10:49: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 * Jeff Behl [010806 12:48] wrote: > please excuse and direct me to the right place if this isn't the appropriate > place to post this sort of question.... > > we're looking into moving to freebsd (yea!), but found the following > problem. It seems that the shortest amount of time the below code will > sleep for is 20 seconds! any call to nanosleep for 5,10, etc miliseconds > returns a 20 ms delay. are we doing something wrong? You may have to increase the kernel value for HZ so that you get more fine grained clock interrupts. -- -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 6 17:43:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pdxpo.dsl-only.net (sub16-3.member.dsl-only.net [63.105.16.3]) by hub.freebsd.org (Postfix) with ESMTP id 0697B37B401 for ; Mon, 6 Aug 2001 17:43:31 -0700 (PDT) (envelope-from pdxmax@dsl-only.net) Received: from tabor.office.archimedesoft.com (unverified [63.105.19.225]) by pdxpo.dsl-only.net (Rockliffe SMTPRA 4.5.4) with ESMTP id for ; Mon, 6 Aug 2001 17:39:08 -0700 Date: Mon, 6 Aug 2001 17:43:30 -0700 From: Tabor Kelly X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Tabor Kelly X-Priority: 3 (Normal) Message-ID: <33375409.20010806174330@dsl-only.net> To: freebsd-hackers@freebsd.org Subject: Kernel Symbol Question 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 Which source file(s) are the kernel symbols defined in? By symbols I mean the symbols that the nlist() man page refers to. Besides the source files, is there any other place that the symbols (their names and meaning) are documented? Thank You, Tabor Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 19:12:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id A295E37B405 for ; Mon, 6 Aug 2001 19:12:57 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.4/8.11.4) id f772Ctg15637; Mon, 6 Aug 2001 21:12:55 -0500 (CDT) (envelope-from dan) Date: Mon, 6 Aug 2001 21:12:55 -0500 From: Dan Nelson To: Tabor Kelly Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Symbol Question Message-ID: <20010806211254.B24699@dan.emsphone.com> References: <33375409.20010806174330@dsl-only.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33375409.20010806174330@dsl-only.net> User-Agent: Mutt/1.3.20i X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Aug 06), Tabor Kelly said: > Which source file(s) are the kernel symbols defined in? By symbols I > mean the symbols that the nlist() man page refers to. /usr/src/sys/**/*.c ; about 1800 files. Any global variable not declared "static" is visible. -- Dan Nelson dnelson@emsphone.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 6 19:30:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f33.pav2.hotmail.com [64.4.37.33]) by hub.freebsd.org (Postfix) with ESMTP id 3525937B405 for ; Mon, 6 Aug 2001 19:30:28 -0700 (PDT) (envelope-from weiguang_shi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 6 Aug 2001 19:30:27 -0700 Received: from 129.128.29.128 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 07 Aug 2001 02:30:27 GMT X-Originating-IP: [129.128.29.128] From: "Weiguang SHI" To: pdxmax@dsl-only.net, freebsd-hackers@freebsd.org Subject: Re: Kernel Symbol Question Date: Mon, 06 Aug 2001 20:30:27 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Aug 2001 02:30:27.0502 (UTC) FILETIME=[EB7ABCE0:01C11EE8] Sender: owner-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, >From: Tabor Kelly >Reply-To: Tabor Kelly >To: freebsd-hackers@freebsd.org >Subject: Kernel Symbol Question >Date: Mon, 6 Aug 2001 17:43:30 -0700 > >Which source file(s) are the kernel symbols defined in? By symbols I >mean the symbols that the nlist() man page refers to. I think you can do a $ nm -g /kernel to view all the external symbols and their addresses in the running kernel. > >Besides the source files, is there any other place that the symbols >(their names and meaning) are documented? I have the same question but seriously doubt there is. Still I hope I will be surprised. Good Luck Weiguang _________________________________________________________________ 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 Mon Aug 6 19:44:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.rnd.runnet.ru (ns.rnd.runnet.ru [195.208.252.78]) by hub.freebsd.org (Postfix) with ESMTP id 79A7137B406; Mon, 6 Aug 2001 19:44:21 -0700 (PDT) (envelope-from max@rsu.ru) Received: from altos (max@altos.rsu.ru [195.208.252.79]) by ns.rnd.runnet.ru (8.9.3/8.9.3) with ESMTP id GAA77909; Tue, 7 Aug 2001 06:44:07 +0400 (MSD) Date: Tue, 7 Aug 2001 06:44:05 +0400 (MSD) From: Maxim Bolotin To: Nick Hibma Cc: freebsd-hackers@freebsd.org, mb@freebsd.org Subject: SmartMedia cards and stuff. 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 Hi, I'm trying to find out what I have to add to make it works. here's what I have: FreeBSD 4.4-PRERELEASE #12: Mon Aug 6 19:13:32 PDT 2001 uhci0: port 0xd400-0xd41f irq 9 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 umass0: Fuji Photo Film Co., Ltd. USB Mass Storage, rev 1.10/10.00, addr 2 umass0:0:0:-1: Attached to scbus0 as device 0 uhci1: port 0xd000-0xd01f irq 9 at device 4.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:24,0 (probe0:umass-sim0:0:0:0): Invalid field in CDB Creating DISK da0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: 150KB/s transfers I just comment out ATAPI part in the file umass.c It seems to me it doesn't support such command, what should I add to avoid it? Regards, Max. - Software Engineer, Genesys Telecommunications Laboratories, Inc. an independent wholly owned subsidiary of Alcatel 1155 Market st, San Francisco, CA 94103, US. (415) 355 5002, maximb@genesyslab.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 6 19:51: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from speedracer.speedtoys.com (speedracer.speedtoys.com [216.36.69.26]) by hub.freebsd.org (Postfix) with ESMTP id A734137B403 for ; Mon, 6 Aug 2001 19:51:01 -0700 (PDT) (envelope-from gemohler@www.speedtoys.com) Received: from localhost (gemohler@localhost) by speedracer.speedtoys.com (8.11.3/8.11.1) with ESMTP id f77351H73984 for ; Mon, 6 Aug 2001 20:05:01 -0700 (PDT) Date: Mon, 6 Aug 2001 20:05:01 -0700 (PDT) From: Geoff Mohler X-Sender: gemohler@speedracer.speedtoys.com To: freebsd-hackers@freebsd.org Subject: -Stable installation... 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 Whats a good reference guide on how to install a -STABLE release? Thanks. --- ******************************************* *New & Improved: http://www.speedtoys.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 6 21: 7:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from blueyonder.co.uk (pcow028o.blueyonder.co.uk [195.188.53.124]) by hub.freebsd.org (Postfix) with ESMTP id 6F0AA37B401 for ; Mon, 6 Aug 2001 21:07:54 -0700 (PDT) (envelope-from andrew@cream.org) Received: from spatula.home ([62.31.80.67]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 7 Aug 2001 05:07:58 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Andrew Boothman To: Geoff Mohler , freebsd-hackers@freebsd.org Subject: Re: -Stable installation... Date: Tue, 7 Aug 2001 05:07:55 +0100 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01080705075504.00404@spatula.home> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 07 August 2001 4:05 am, Geoff Mohler wrote: > Whats a good reference guide on how to install a -STABLE release? The handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html and the freebsd-stable mailing list, which you should subscribe to and read in order to keep up with the latest comings and goings. An archive of recent messages is available from http://docs.freebsd.org/mail/current/freebsd-stable.html -- Andrew Boothman http://sour.cream.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 6 22:52:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 25C5137B403 for ; Mon, 6 Aug 2001 22:52:56 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.136.130.Dial1.SanJose1.Level3.net [209.245.136.130]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA03282; Mon, 6 Aug 2001 22:52:53 -0700 (PDT) Message-ID: <3B6F825E.341B4AF2@mindspring.com> Date: Mon, 06 Aug 2001 22:53:34 -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: Alexander Litvin Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: gethostbyXXXX_r() References: <200108050818.f758IjT60048@unknown.whichever.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alexander Litvin wrote: > As for bind9 -- this has AFAIK totally rewritten resolver, > which doesn't even resemble bind8. IMHO, to incorporate > it into FreeBSD might take a tremendous effort. Not really. Just import it on a vendor branch as /usr/src/lib/libresolv, and then things that want it can link to it, no problem. Once everything is converted over, then it can be diked out of libc. Pretty straight forward... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 23: 8:12 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 527B337B401 for ; Mon, 6 Aug 2001 23:08:10 -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 f77688l01164; Tue, 7 Aug 2001 00:08:08 -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 f77687111610; Tue, 7 Aug 2001 00:08:08 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108070608.f77687111610@harmony.village.org> To: Assem Salama Subject: Re: detach Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 06 Aug 2001 12:16:37 EDT." <3B6EC2E5.CF2077FC@twcny.rr.com> References: <3B6EC2E5.CF2077FC@twcny.rr.com> Date: Tue, 07 Aug 2001 00:08:07 -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 <3B6EC2E5.CF2077FC@twcny.rr.com> Assem Salama writes: : Hello, : I have a question. I'm trying to make a module for a PCI card. My : problem is my 'detach' function never get's called when I unload the : module. Al my other functions get called correctly. Here is my source: Don't use uprintf in drivers. Use printf instead. Is DEBUG defined? Becuase I know that my detach routines are getting called and I define them just this way. 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 6 23:27:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 8BCE037B401 for ; Mon, 6 Aug 2001 23:27:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.136.130.Dial1.SanJose1.Level3.net [209.245.136.130]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA14061; Mon, 6 Aug 2001 23:27:15 -0700 (PDT) Message-ID: <3B6F8A6C.B95966B7@mindspring.com> Date: Mon, 06 Aug 2001 23:27:56 -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: Matt Dillon Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time References: <200108051955.f75Jtk882156@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 Dillon wrote: > Yes, that is precisely the reason. In -current this all changes, though, > since interrupts are now threads. *But*, that said, interrupts cannot > really afford to hold mutexes that might end up blocking them for > long periods of time so I would still recommend that interrupt code not > attempt to allocate pages out of PQ_CACHE. I keep wondering about the sagicity of running interrupts in threads... it still seems like an incredibly bad idea to me. I guess my major problem with this is that by running in threads, it's made it nearly impossibly to avoid receiver livelock situations, using any of the classical techniques (e.g. Mogul's work, etc.). It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with the big giant lock and redirecting interrupts to "the CPU in the kernel" is better than that... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 6 23:37:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 632D537B403 for ; Mon, 6 Aug 2001 23:37:36 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=ff369070a3cfb3ef85e67eed08858528) by softweyr.com with esmtp (Exim 3.16 #1) id 15U0cQ-0000CR-00; Tue, 07 Aug 2001 00:45:34 -0600 Message-ID: <3B6F8E8E.DFBE1E0C@softweyr.com> Date: Tue, 07 Aug 2001 00:45:34 -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: Tabor Kelly Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Symbol Question References: <33375409.20010806174330@dsl-only.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Tabor Kelly wrote: > > Which source file(s) are the kernel symbols defined in? By symbols I > mean the symbols that the nlist() man page refers to. Let's see... The nlist() function retrieves name list entries from the symbol table of an executable file (see a.out(5)). In the case of the kernel, that would be the kernel you booted, typically /kernel. > Besides the source files, is there any other place that the symbols > (their names and meaning) are documented? The section 9 man pages. Actually, you're lucky if they're documented in the source... -- "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 7 0:16: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id D123D37B401 for ; Tue, 7 Aug 2001 00:15:57 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f777IWS46144; Tue, 7 Aug 2001 03:18:32 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 7 Aug 2001 03:18:32 -0400 From: Bosko Milekic To: Terry Lambert Cc: Matt Dillon , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Message-ID: <20010807031832.A46112@technokratis.com> References: <200108051955.f75Jtk882156@earth.backplane.com> <3B6F8A6C.B95966B7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6F8A6C.B95966B7@mindspring.com>; from tlambert2@mindspring.com on Mon, Aug 06, 2001 at 11:27:56PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 06, 2001 at 11:27:56PM -0700, Terry Lambert wrote: > I keep wondering about the sagicity of running interrupts in > threads... it still seems like an incredibly bad idea to me. > > I guess my major problem with this is that by running in > threads, it's made it nearly impossibly to avoid receiver > livelock situations, using any of the classical techniques > (e.g. Mogul's work, etc.). References to published works? > It also has the unfortunate property of locking us into virtual > wire mode, when in fact Microsoft demonstrated that wiring down > interrupts to particular CPUs was good practice, in terms of > assuring best performance. Specifically, running in virtual Can you point us at any concrete information that shows this? Specifically, without being Microsoft biased (as is most "data" published by Microsoft)? -- i.e. preferably third-party performance testing that attributes wiring down of interrupts to particular CPUs as _the_ performance advantage. > wire mode means that all your CPUs get hit with the interrupt, > whereas running with the interrupt bound to a particular CPU > reduces the overall overhead. Even what we have today, with Obviously. > the big giant lock and redirecting interrupts to "the CPU in > the kernel" is better than that... > > -- Terry -- 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 Tue Aug 7 0:19: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 1522737B401 for ; Tue, 7 Aug 2001 00:19:55 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CE12181D0A; Tue, 7 Aug 2001 02:19:54 -0500 (CDT) Date: Tue, 7 Aug 2001 02:19:54 -0500 From: Alfred Perlstein To: Bosko Milekic Cc: Terry Lambert , Matt Dillon , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Message-ID: <20010807021954.Q85642@elvis.mu.org> References: <200108051955.f75Jtk882156@earth.backplane.com> <3B6F8A6C.B95966B7@mindspring.com> <20010807031832.A46112@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010807031832.A46112@technokratis.com>; from bmilekic@technokratis.com on Tue, Aug 07, 2001 at 03:18:32AM -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 * Bosko Milekic [010807 02:16] wrote: > > On Mon, Aug 06, 2001 at 11:27:56PM -0700, Terry Lambert wrote: > > I keep wondering about the sagicity of running interrupts in > > threads... it still seems like an incredibly bad idea to me. > > > > I guess my major problem with this is that by running in > > threads, it's made it nearly impossibly to avoid receiver > > livelock situations, using any of the classical techniques > > (e.g. Mogul's work, etc.). > > References to published works? > > > It also has the unfortunate property of locking us into virtual > > wire mode, when in fact Microsoft demonstrated that wiring down > > interrupts to particular CPUs was good practice, in terms of > > assuring best performance. Specifically, running in virtual > > Can you point us at any concrete information that shows this? > Specifically, without being Microsoft biased (as is most "data" published by > Microsoft)? -- i.e. preferably third-party performance testing that attributes > wiring down of interrupts to particular CPUs as _the_ performance advantage. > > > wire mode means that all your CPUs get hit with the interrupt, > > whereas running with the interrupt bound to a particular CPU > > reduces the overall overhead. Even what we have today, with > > Obviously. > > > the big giant lock and redirecting interrupts to "the CPU in > > the kernel" is better than that... I really don't see what part of the current design specifically disallows one to both: 1) force interrupts to be taken on a particular cpu. 2) if that thread gets switched out, have it put on a per-cpu runqueue when it becomes runable preventing another cpu from snatching it up. I've already implemented #2, #1 requires touching hardware which isn't something I like doing. :) -- -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 7 0:35:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 7A62A37B403 for ; Tue, 7 Aug 2001 00:35:19 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.136.130.Dial1.SanJose1.Level3.net [209.245.136.130]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA09371; Tue, 7 Aug 2001 00:35:17 -0700 (PDT) Message-ID: <3B6F9A5E.A58E9F31@mindspring.com> Date: Tue, 07 Aug 2001 00:35:58 -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: Jeff Behl Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: timing question References: <0307F3737A2AD511A42200D0B7A071919A402F@dopey.corp.expertcity.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 Jeff Behl wrote: > please excuse and direct me to the right place if this isn't the appropriate > place to post this sort of question.... > > we're looking into moving to freebsd (yea!), but found the following > problem. It seems that the shortest amount of time the below code will > sleep for is 20 seconds! any call to nanosleep for 5,10, etc miliseconds > returns a 20 ms delay. are we doing something wrong? You appear to be measuring the quantum. You can decrease the quantum size via sysctl, or at compile time. Realize that your timing is tight enough that if you are running any other code, you can't expect that your process will get the quantum next, unless you use rtprio. Also note that your timer granularity might be someone less than you would expect: in other words it could be returning before, but since the sleep is woken up as the result of a timer interrupt firing, you may need to increase the rate your clock runs at (search for "HZ" in /sys/i386/conf/LINT) to make your timer interrupts faster, which will in turn increase your timeout resolution. -- 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 7 0:38:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 88E0137B405 for ; Tue, 7 Aug 2001 00:38:19 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f777dmi08218; Tue, 7 Aug 2001 00:39:49 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108070739.f777dmi08218@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: tlambert2@mindspring.com Cc: Matt Dillon , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time In-reply-to: Your message of "Mon, 06 Aug 2001 23:27:56 PDT." <3B6F8A6C.B95966B7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Aug 2001 00:39:48 -0700 From: Mike Smith Sender: owner-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 also has the unfortunate property of locking us into virtual > wire mode, when in fact Microsoft demonstrated that wiring down > interrupts to particular CPUs was good practice, in terms of > assuring best performance. Specifically, running in virtual > wire mode means that all your CPUs get hit with the interrupt, > whereas running with the interrupt bound to a particular CPU > reduces the overall overhead. Even what we have today, with > the big giant lock and redirecting interrupts to "the CPU in > the kernel" is better than that... Terry, this is *total* garbage. Just so you know, ok? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 0:42:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 400E437B401 for ; Tue, 7 Aug 2001 00:42:44 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com ident=c47a6766d893bf7e4876898afaf290fb) by softweyr.com with esmtp (Exim 3.16 #1) id 15U1cv-0000Dz-00; Tue, 07 Aug 2001 01:50:10 -0600 Message-ID: <3B6F9DB1.9DA1BAC0@softweyr.com> Date: Tue, 07 Aug 2001 01:50:09 -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: "Richard Seaman, Jr." Cc: Alfred Perlstein , Alexander Litvin , freebsd-hackers@FreeBSD.ORG Subject: Re: gethostbyXXXX_r() References: <20010803105321.A37737@unknown.whichever.org> <20010803131115.F85642@elvis.mu.org> <3B6B9052.5FE460B7@softweyr.com> <20010804090821.E1119@seaman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Richard Seaman, Jr." wrote: > > On Sat, Aug 04, 2001 at 12:04:02AM -0600, Wes Peters wrote: > > Alfred Perlstein wrote: > > > > > > * Alexander Litvin [010803 09:54] wrote: > > > > Are there any plans of making gethostbyname_r() and gethostbyaddr_r() > > > > available in FreeBSD? May be somebody already has them almost ready > > > > to be commited? Or are there any considered wrong way to go? > > > > > > > > The reason I'm asking is that I actually have a local patch implementing > > > > them here (only for DNS for now). Is it good idea to put some effort to > > > > finalaze it and submit a PR? Or I'd better not waist time on that? > > > > > > Please complete it, let me know when you submit the PR i'll try > > > to get it integrated. > > > > I'll be happy to take a look at it too. I did a lot of the _r routines > > we have now, in some cases simply documenting ones that were there, but > > halted when I got to gethostbyX_r and the passwd and group variants, > > because they were too fugly to tackle at that time. I'll get back to > > the > > remainder "someday", when I have the time, unless you beat me to it. > > There are some gethostby_r, getnetby_r, ... etc routines in the > linuxthreads port (/usr/ports/devel/linuxthreads/files). These > came from the original linuxthreads package, and have no copyright > on them. I never researched the copyright status of them, but > I don't think they are GPL, though you might want to do further > research on their history if you use them. If they're just mutex-protected variants, I haven't bothered to create any of those. I guess they might be of use to somebody, but I very much wanted to create _r routines that were implemented properly, not just wrap the non-_r routines in a mutex, which is bass-ackwards. -- "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 7 1:58:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 3319D37B401 for ; Tue, 7 Aug 2001 01:58:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.136.130.Dial1.SanJose1.Level3.net [209.245.136.130]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA18432; Tue, 7 Aug 2001 01:57:40 -0700 (PDT) Message-ID: <3B6FADAD.C8CC14C5@mindspring.com> Date: Tue, 07 Aug 2001 01:58:21 -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: Bosko Milekic Cc: Matt Dillon , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time References: <200108051955.f75Jtk882156@earth.backplane.com> <3B6F8A6C.B95966B7@mindspring.com> <20010807031832.A46112@technokratis.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 Bosko Milekic wrote: > > I keep wondering about the sagicity of running interrupts in > > threads... it still seems like an incredibly bad idea to me. > > > > I guess my major problem with this is that by running in > > threads, it's made it nearly impossibly to avoid receiver > > livelock situations, using any of the classical techniques > > (e.g. Mogul's work, etc.). > > References to published works? Just do an NCSTRL search on "receiver livelock"; you will get over 90 papers... http://ncstrl.mit.edu/ See also the list of participating institutions: http://ncstrl.mit.edu/Dienst/UI/2.0/ListPublishers It won't be that hard to find... Mogul has "only" published 92 papers. 8-) > > It also has the unfortunate property of locking us into virtual > > wire mode, when in fact Microsoft demonstrated that wiring down > > interrupts to particular CPUs was good practice, in terms of > > assuring best performance. Specifically, running in virtual > > Can you point us at any concrete information that shows > this? Specifically, without being Microsoft biased (as is most > "data" published by Microsoft)? -- i.e. preferably third-party > performance testing that attributes wiring down of interrupts to > particular CPUs as _the_ performance advantage. FreeBSD was tested, along with Linux and NT, by Ziff Davis Labs, in Foster city, with the participation of Jordan Hubbard and Mike Smith. You can ask either of them for the results of the test; only the Linux and NT numbers were actually released. This was done to provide a non-biased baseline, in reaction to the Mindcraft benchmarks, where Linux showed so poorly. They ran quad ethernet cards, with quad CPUs; the NT drivers wired the cards down to seperate INT A/B/C/D interrupts, one per CPU. > > wire mode means that all your CPUs get hit with the interrupt, > > whereas running with the interrupt bound to a particular CPU > > reduces the overall overhead. Even what we have today, with > > Obviously. I mention it because this is the direction FreeBSD appears to be moving in. Right now, Intel is shipping with seperate PCI busses; there is one motherboard from their serverworks division that has 16 seperate PCI busses -- which means that you can do simultaneous gigabit card DMA to and from memory, without running into bus contention, so long as the memory is logically seperate. NT can use this hardware to its full potential; FreeBSD as it exists, can not, and FreeBSD as it appears to be heading today (interrupt threads, etc.) seems to be in the same boat as Linux, et. al.. PCI-X will only make things worse (8.4 gigabit, burst rate). -- 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 7 2:10:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 32D3537B403; Tue, 7 Aug 2001 02:10:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.136.130.Dial1.SanJose1.Level3.net [209.245.136.130]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA04959; Tue, 7 Aug 2001 02:10:29 -0700 (PDT) Message-ID: <3B6FB0AE.8D40EF5D@mindspring.com> Date: Tue, 07 Aug 2001 02:11:10 -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: Mike Smith Cc: Matt Dillon , Zhihui Zhang , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > > > It also has the unfortunate property of locking us into virtual > > wire mode, when in fact Microsoft demonstrated that wiring down > > interrupts to particular CPUs was good practice, in terms of > > assuring best performance. Specifically, running in virtual > > wire mode means that all your CPUs get hit with the interrupt, > > whereas running with the interrupt bound to a particular CPU > > reduces the overall overhead. Even what we have today, with > > the big giant lock and redirecting interrupts to "the CPU in > > the kernel" is better than that... > > Terry, this is *total* garbage. > > Just so you know, ok? What "this", exactly? That "virtual wire" mode is actually a bad idea for some applications -- specifically, high speed networking with multiple gigabit ethernet cards? That Microsoft demonstrated that wiring down interrupts to a particular CPU was a good idea, and kicked both Linux' and FreeBSD's butt in the test at ZD Labs? That taking interrupts on a single directed CPU is better than taking an IPI on all your CPUs, and then sorting out who's going to handle the interrupt? Can you name one SMP OS implementation that uses an "interrupt threads" approach that doesn't hit a scaling wall at 4 (or fewer) CPUs, due to heavier weight thread context switch overhead? Can you tell me how, in the context of having an interrupt thread doing scheduled processing, how you could avoid an interrupt overhead livelock, where the thread doesn't get opportunity to run because you're too busy taking interrupts to be able to get any work done? FWIW, I would be happy to cite sources to you, off the general list. -- 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 7 6:58:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 5CF2937B403 for ; Tue, 7 Aug 2001 06:57:39 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.5/8.11.4) id f77HudU83274 for freebsd-hackers@freebsd.org; Tue, 7 Aug 2001 17:56:39 GMT (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108071756.f77HudU83274@bugz.infotecs.ru> Subject: [PATCH] pam_wheel fix To: freebsd-hackers@freebsd.org Date: Tue, 7 Aug 2001 17:56:39 +0000 (GMT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.83211.997206999--%" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --%--multipart-mixed-boundary-1.83211.997206999--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, can anyone please commit this fix to pam_wheel authentication module. It fixed two problem I mentioned in my previous mail (currently for any non-root user PAM_IGNORE is returned, and in case of auth_as_self and debug options used together it logs strange things instead of username). The patch must be applied in src/lib/libpam/modules/pam_wheel/ Regards, Eugene --%--multipart-mixed-boundary-1.83211.997206999--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: ASCII C program text Content-Disposition: attachment; filename="pam_wheel.patch" --- pam_wheel_old.c Tue Aug 7 17:46:20 2001 +++ pam_wheel.c Tue Aug 7 17:48:04 2001 @@ -84,11 +84,14 @@ PAM_RETURN(retval); pwd = getpwnam(user); } + + if (!pwd) + PAM_RETURN(PAM_IGNORE); - PAM_LOG("Got user: %s", user); + PAM_LOG("Got user: %s", pwd->pw_name); /* Ignore if already uid 0 */ - if (pwd->pw_uid) + if (!pwd->pw_uid) PAM_RETURN(PAM_IGNORE); PAM_LOG("Not superuser"); --%--multipart-mixed-boundary-1.83211.997206999--%-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 8: 8: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by hub.freebsd.org (Postfix) with ESMTP id 1ACEA37B409 for ; Tue, 7 Aug 2001 08:08:04 -0700 (PDT) (envelope-from bwithrow@BayNetworks.COM) Received: from mailhost.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id HAA24167 for ; Tue, 7 Aug 2001 07:57:03 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA01506 for ; Tue, 7 Aug 2001 08:05:38 -0700 (PDT) Received: from baynetworks.com (tuva [192.32.150.102]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id LAA18256; Tue, 7 Aug 2001 11:07:47 -0400 for Message-Id: <200108071507.LAA18256@pobox.engeast.BayNetworks.COM> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: hackers@freebsd.org Cc: bwithrow@engeast.BayNetworks.COM Subject: Ypbind malfunction on 4.x Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Aug 2001 11:07:48 -0400 From: Robert Withrow Sender: owner-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: If I'm posting to the wrong list, please let me know. There is a long-running problem in FreeBSD's yp/ypbind that is evidenced by: Aug 4 02:01:43 tuva ypbind[160]: NIS server [192.32.150.15] for domain "engeast" not responding Aug 4 02:02:14 tuva last message repeated 30 times Aug 4 02:04:15 tuva last message repeated 121 times (And there would be other messages about throttling icmp messages, except I've applied a patch to ypbind.c that at least throttles things down to 1 message per second. This patch was posted to questions.) ... and it never rebinds to any other server. The only way I've found to fix the problem is to reboot. I am experiencing this in 4.3 Release, and I've had it in 4.2 and earlier. This problem has seen a little discussion in questions. But I've never seen anything in any of the lists about a solution to the core problem. Maybe I've missed this? Anyone working on this? It is a pretty serious problem (since you basically can't do anything once it happens in typical NIS/Amd installations). I'd appreciate, at least, knowing if there is a non-reboot work-around. Thanks! -- Robert Withrow -- (+1 978 288 8256, ESN 248) BWithrow@NortelNetworks.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 7 8:20:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by hub.freebsd.org (Postfix) with ESMTP id 9A8B537B406 for ; Tue, 7 Aug 2001 08:20:15 -0700 (PDT) (envelope-from K.J.Koster@kpn.com) Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 17:20:13 +0100 Message-ID: <59063B5B4D98D311BC0D0001FA7E452205FD9E8C@l04.research.kpn.com> From: "Koster, K.J." To: "'les@safety.net'" Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: dmesg behaviour Date: Tue, 7 Aug 2001 17:20:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Dear, > > On the supermicro > systems, we may see the information from the last 3 boots! I see the > lines: > > syncing disks... done > Rebooting... > > and then we go right into the next boot. At present, one of > the machines shows all the detail from 2.75 reboots. > > How and why is it doing this, and how do I make it stop? > FWIW, FreeBSD/alpha also exhibits this behaviour. Perhaps it's better to adapt your tools to cope to improve their portability between FreeBSD-supported architectures? Kees Jan ===================================================== You can't have everything. Where would you put it? [Steven Wright] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 8:28:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (beleriand.online.bg [217.75.129.181]) by hub.freebsd.org (Postfix) with SMTP id D9E0837B414 for ; Tue, 7 Aug 2001 08:28:27 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 1614 invoked by uid 1000); 7 Aug 2001 15:27:16 -0000 Date: Tue, 7 Aug 2001 18:27:16 +0300 From: Peter Pentchev To: Robert Withrow Cc: hackers@freebsd.org, bwithrow@engeast.BayNetworks.COM Subject: Re: Ypbind malfunction on 4.x Message-ID: <20010807182716.B465@ringworld.oblivion.bg> Mail-Followup-To: Robert Withrow , hackers@freebsd.org, bwithrow@engeast.BayNetworks.COM References: <200108071507.LAA18256@pobox.engeast.BayNetworks.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108071507.LAA18256@pobox.engeast.BayNetworks.COM>; from bwithrow@nortelnetworks.com on Tue, Aug 07, 2001 at 11:07:48AM -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 I think that there has been quite a lot of work on ypbind recently. Try updating to 4.3-STABLE (actually 4.4-PRERELEASE now), there were several patches in that area in the past week or two. Or alternatively, wait for 4.4-RELEASE about the end of August. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? On Tue, Aug 07, 2001 at 11:07:48AM -0400, Robert Withrow wrote: > Hi: > > If I'm posting to the wrong list, please let me know. > > There is a long-running problem in FreeBSD's yp/ypbind that is > evidenced by: > > Aug 4 02:01:43 tuva ypbind[160]: NIS server [192.32.150.15] for domain "engeast" not responding > Aug 4 02:02:14 tuva last message repeated 30 times > Aug 4 02:04:15 tuva last message repeated 121 times > > (And there would be other messages about throttling icmp messages, except > I've applied a patch to ypbind.c that at least throttles things down to > 1 message per second. This patch was posted to questions.) > > ... and it never rebinds to any other server. The only way I've found > to fix the problem is to reboot. > > I am experiencing this in 4.3 Release, and I've had it in 4.2 and earlier. > > This problem has seen a little discussion in questions. But I've never seen > anything in any of the lists about a solution to the core problem. Maybe > I've missed this? > > Anyone working on this? It is a pretty serious problem (since you basically > can't do anything once it happens in typical NIS/Amd installations). I'd > appreciate, at least, knowing if there is a non-reboot work-around. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 9:11:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f49.pav2.hotmail.com [64.4.37.49]) by hub.freebsd.org (Postfix) with ESMTP id 96FB237B405 for ; Tue, 7 Aug 2001 09:11:11 -0700 (PDT) (envelope-from weiguang_shi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 Aug 2001 09:11:11 -0700 Received: from 129.128.29.128 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 07 Aug 2001 16:11:11 GMT X-Originating-IP: [129.128.29.128] From: "Weiguang SHI" To: bright@mu.org, jeff@expertcity.com Cc: freebsd-hackers@freebsd.org Subject: Re: timing question Date: Tue, 07 Aug 2001 10:11:11 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Aug 2001 16:11:11.0396 (UTC) FILETIME=[9320A640:01C11F5B] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >From: Alfred Perlstein >To: Jeff Behl >CC: "'freebsd-hackers@freebsd.org'" >Subject: Re: timing question >Date: Mon, 6 Aug 2001 14:49:55 -0500 > >* Jeff Behl [010806 12:48] wrote: > > please excuse and direct me to the right place if this isn't the >appropriate > > place to post this sort of question.... > > > > we're looking into moving to freebsd (yea!), but found the following > > problem. It seems that the shortest amount of time the below code will > > sleep for is 20 seconds! any call to nanosleep for 5,10, etc >miliseconds > > returns a 20 ms delay. are we doing something wrong? > >You may have to increase the kernel value for HZ so that you get >more fine grained clock interrupts. I didn't look at the code but if increasing the value of 'hz' will result in more clock-interrupts/sec thus more overhead, wouldn't it be better to auto-adjust the clock-interrupt rate somewhere in the OS to clock-interrupt at big strides in the beginning but at finer-grained interval as the actual timeout event approaches? Weiguang _________________________________________________________________ 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 Tue Aug 7 9:17: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from n18.groups.yahoo.com (n18.groups.yahoo.com [216.115.96.68]) by hub.freebsd.org (Postfix) with SMTP id 99B9037B41E for ; Tue, 7 Aug 2001 09:15:39 -0700 (PDT) (envelope-from notify-return-freebsd-hackers=freebsd.org@egroups.co.uk) X-eGroups-Return: notify-return-freebsd-hackers=freebsd.org@egroups.co.uk Received: from [10.1.10.141] by mr.egroups.com with NNFMP; 07 Aug 2001 16:15:31 -0000 Date: 7 Aug 2001 16:15:27 -0000 Message-ID: <997200927.4961.12669.f8@egroups.co.uk> From: freebsd-lists-for-dayan-only Moderator Reply-To: freebsd-lists-for-dayan-only-unsubscribe@egroups.co.uk To: freebsd-hackers@freebsd.org Subject: Welcome to the freebsd-lists-for-dayan-only group MIME-Version: 1.0 Content-Type: text/plain 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 added you to my freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. As a member of this group, you may send messages to the entire group using just one email address: freebsd-lists-for-dayan-only@egroups.co.uk. eGroups also makes it easy to store photos and files, coordinate events, and more. Here's a description of the group: ------------------------------------------------------------------------ This list is subscribed to various FreeBSD lists only for Dayan. ------------------------------------------------------------------------ Here's my introductory message for you: ------------------------------------------------------------------------ Hello, Welcome to the freebsd-lists-for-dayan-only group at eGroups, a free, easy-to-use email group service. Please take a moment to review this message. To start sending messages to members of this group, simply send email to freebsd-lists-for-dayan-only@egroups.co.uk If you do not wish to belong to freebsd-lists-for-dayan-only, you may unsubscribe by sending an email to freebsd-lists-for-dayan-only-unsubscribe@egroups.co.uk You may also visit the eGroups web site to modify your subscriptions: http://www.egroups.co.uk/mygroups Regards, Moderator, freebsd-lists-for-dayan-only ------------------------------------------------------------------------ TO START SENDING messages to members of this group, simply send email to freebsd-lists-for-dayan-only@egroups.co.uk If you do not wish to belong to the freebsd-lists-for-dayan-only group, you can unsubscribe by replying to this message, or by sending an email to freebsd-lists-for-dayan-only-unsubscribe@egroups.co.uk Regards, Moderator, freebsd-lists-for-dayan-only SPECIAL NOTE FROM eGroups: Because eGroups values your privacy, it is a violation of our service rules for moderators to add subscribers to a group against their wishes. If you feel this has happened, please notify us at abuse@egroups.co.uk P.S. If you would like to learn more about the freebsd-lists-for-dayan-only group, please visit http://www.egroups.co.uk/group/freebsd-lists-for-dayan-only and enter the following sign-in information: Email address: freebsd-hackers@freebsd.org Password: yrlacmxklfugtlv This password has been randomly generated for you. Once you have signed in, you should change your password by visiting http://www.egroups.co.uk/myprofile To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 9:30: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 94DAD37B40A for ; Tue, 7 Aug 2001 09:30:52 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 6A73881D0A; Tue, 7 Aug 2001 11:30:52 -0500 (CDT) Date: Tue, 7 Aug 2001 11:30:52 -0500 From: Alfred Perlstein To: Weiguang SHI Cc: jeff@expertcity.com, freebsd-hackers@freebsd.org Subject: Re: timing question Message-ID: <20010807113052.S85642@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 weiguang_shi@hotmail.com on Tue, Aug 07, 2001 at 10:11:11AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Weiguang SHI [010807 11:11] wrote: > > > > >From: Alfred Perlstein > >To: Jeff Behl > >CC: "'freebsd-hackers@freebsd.org'" > >Subject: Re: timing question > >Date: Mon, 6 Aug 2001 14:49:55 -0500 > > > >* Jeff Behl [010806 12:48] wrote: > > > please excuse and direct me to the right place if this isn't the > >appropriate > > > place to post this sort of question.... > > > > > > we're looking into moving to freebsd (yea!), but found the following > > > problem. It seems that the shortest amount of time the below code will > > > sleep for is 20 seconds! any call to nanosleep for 5,10, etc > >miliseconds > > > returns a 20 ms delay. are we doing something wrong? > > > >You may have to increase the kernel value for HZ so that you get > >more fine grained clock interrupts. > > I didn't look at the code but if increasing the value of 'hz' will > result in more clock-interrupts/sec thus more overhead, wouldn't it be > better to auto-adjust the clock-interrupt rate somewhere in the OS > to clock-interrupt at big strides in the beginning but at > finer-grained interval as the actual timeout event approaches? Yes, but that's not trivial, several places in the kernel call tsleep(9) with a timeout value of "5 * hz" to mean 5 seconds, those places would probably have to be fixed up or something done not to prematurely trigger them waking up. I guess the clock code could realize it's in an accelerated state and not update the variables that could cause problems, basically only look for people who need the higher resolution interrupts. "got diffs" ? :) -- -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 7 9:31:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from n33.groups.yahoo.com (n33.groups.yahoo.com [216.115.96.83]) by hub.freebsd.org (Postfix) with SMTP id 71A1837B405 for ; Tue, 7 Aug 2001 09:31:49 -0700 (PDT) (envelope-from notify-return-freebsd-hackers=freebsd.org@egroups.co.uk) X-eGroups-Return: notify-return-freebsd-hackers=freebsd.org@egroups.co.uk Received: from [10.1.10.140] by ei.egroups.com with NNFMP; 07 Aug 2001 16:31:49 -0000 Date: 7 Aug 2001 16:31:49 -0000 Message-ID: <997201909.32.48155.f7@egroups.co.uk> From: eGroups Notification To: freebsd-hackers@freebsd.org Subject: Lost password MIME-Version: 1.0 Content-Type: text/plain 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, Thanks for using eGroups, home to free, easy, email groups. We have received your request for information about a forgotten password. * If you requested this notice and still don't remember your password, please follow these steps to create a new password: 1. In your web browser, go to: http://www.egroups.co.uk/lostpassword?user=freebsd-hackers@freebsd.org 2. Enter this reauthorisation number: 5295 3. You will be asked to create a new permanent password. Your new password cannot be the reauthorisation number. * If you did not request this notice, please ignore this message. Your eGroups account and current password have not been affected and you can continue using our free service as usual. If you believe someone is attempting to misuse your email account, please forward this message to abuse@egroups.co.uk. Regards, eGroups Customer Support To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 9:55:15 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 067C637B40C; Tue, 7 Aug 2001 09:55:11 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f77Gt9M32808; Tue, 7 Aug 2001 09:55:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 7 Aug 2001 09:55:09 -0700 (PDT) From: Matt Dillon Message-Id: <200108071655.f77Gt9M32808@earth.backplane.com> To: Terry Lambert Cc: Mike Smith , Zhihui Zhang , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> > It also has the unfortunate property of locking us into virtual :> > wire mode, when in fact Microsoft demonstrated that wiring down :> > interrupts to particular CPUs was good practice, in terms of :> > assuring best performance. Specifically, running in virtual :> > wire mode means that all your CPUs get hit with the interrupt, :> > whereas running with the interrupt bound to a particular CPU :> > reduces the overall overhead. Even what we have today, with :> > the big giant lock and redirecting interrupts to "the CPU in :> > the kernel" is better than that... :> :> Terry, this is *total* garbage. :> :> Just so you know, ok? : :What "this", exactly? : :That "virtual wire" mode is actually a bad idea for some :applications -- specifically, high speed networking with :multiple gigabit ethernet cards? All the cpu's don't get the interrupt, only one does. :That Microsoft demonstrated that wiring down interrupts :to a particular CPU was a good idea, and kicked both Linux' :and FreeBSD's butt in the test at ZD Labs? Well, if you happen to have four NICs and four CPUs, and you are running them all full bore, I would say that wiring the NICs to the CPUs would be a good idea. That seems like a rather specialized situation, though. -Matt :That taking interrupts on a single directed CPU is better :than taking an IPI on all your CPUs, and then sorting out :who's going to handle the interrupt? :... : :-- 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 7 9:59:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id D55E237B409; Tue, 7 Aug 2001 09:59:39 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f77Gxc333362; Tue, 7 Aug 2001 12:59:38 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200108070739.f777dmi08218@mass.dis.org> References: <200108070739.f777dmi08218@mass.dis.org> Date: Tue, 7 Aug 2001 12:59:36 -0400 To: Mike Smith , tlambert2@mindspring.com From: Garance A Drosihn Subject: Re: Allocate a page at interrupt time Cc: Matt Dillon , freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:39 AM -0700 8/7/01, Mike Smith wrote: > > It also has the unfortunate property of locking us into virtual >> wire mode, when in fact Microsoft demonstrated that wiring down >> interrupts to particular CPUs was good practice, in terms of >> assuring best performance. Specifically, running in virtual >> wire mode means that all your CPUs get hit with the interrupt, >> whereas running with the interrupt bound to a particular CPU >> reduces the overall overhead. Even what we have today, with >> the big giant lock and redirecting interrupts to "the CPU in >> the kernel" is better than that... > >Terry, this is *total* garbage. > >Just so you know, ok? There are people on this list besides Terry. Terry has taken the time to refer to a few URL's, and remind us of a benchmark that I (for one) do remember, and I do remember Windows doing quite well on it. Maybe that benchmark was bogus for some reason, but I seem to remember several freebsd developers taking it seriously at the time. So, could you at least fill in what part of the above is total garbage? Throw in a few insults to Terry if it makes you feel better for some reason, but raise the level of information content a little for the rest of us? You quoted several distinct comments of Terry's -- were all of them garbage? It might very well be that all of Terry's comments were in fact garbage, but from the sidelines I'd appreciate a little more in the way of technical details. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 10: 8:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 000BD37B40D; Tue, 7 Aug 2001 10:08:12 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f77H8A374634; Tue, 7 Aug 2001 13:08:11 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200108071655.f77Gt9M32808@earth.backplane.com> References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <200108071655.f77Gt9M32808@earth.backplane.com> Date: Tue, 7 Aug 2001 13:08:08 -0400 To: Matt Dillon , Terry Lambert From: Garance A Drosihn Subject: Re: Allocate a page at interrupt time Cc: Mike Smith , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:55 AM -0700 8/7/01, Matt Dillon wrote: >:> > It also has the unfortunate property of locking us into virtual >:> > wire mode, when in fact Microsoft demonstrated that wiring down >:> > interrupts to particular CPUs was good practice, in terms of >:> > assuring best performance. [...] >:> >:> Terry, this is *total* garbage. >:> >:> Just so you know, ok? >: >:What "this", exactly? >: >:That "virtual wire" mode is actually a bad idea for some >:applications -- specifically, high speed networking with >:multiple gigabit ethernet cards? > > All the cpu's don't get the interrupt, only one does. > >:That Microsoft demonstrated that wiring down interrupts >:to a particular CPU was a good idea, and kicked both Linux' >:and FreeBSD's butt in the test at ZD Labs? > > Well, if you happen to have four NICs and four CPUs, and > you are running them all full bore, I would say that > wiring the NICs to the CPUs would be a good idea. That > seems like a rather specialized situation, though. Okay, that's helpful to sort out the discussion. I'd agree that is a specialized situation, one which wouldn't be critical to many freebsd users. Is Terry right that the current strategy will "lock us into virtual wire mode", in some way which means that this specialized situation CANNOT be handled? (it would be fine if it were "handled" via some specialized kernel option, imo. I'm just wondering what the limitations are. I do not mean to imply we should follow some different strategy here, I'm just wondering...) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 10:17:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ntlg.sibnet.ru (dns.sibnet.ru [217.70.96.34]) by hub.freebsd.org (Postfix) with ESMTP id 546ED37B403 for ; Tue, 7 Aug 2001 10:17:22 -0700 (PDT) (envelope-from semenu@FreeBSD.org) Received: from tlg5-ppp42.sibnet.ru (tlg5-ppp42.sibnet.ru [217.70.97.43]) by ntlg.sibnet.ru (8.9.3+Sun/8.9.3) with ESMTP id VAA06769 for ; Tue, 7 Aug 2001 21:17:15 +0400 (MSD) Date: Wed, 8 Aug 2001 00:17:13 +0600 (GMT+6) From: "Semen A. Ustimenko" X-Sender: semenu@default To: freebsd-hackers@FreeBSD.org Subject: Kernel stack size 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 Hi! I'm developing some code running in kernel that use a lot of stack. And it seems i run into stack overflow. This results in some proc structure related parts overwrite (particulary p->p_stats->p_timer[ITIMER_PROF]) and unexpected signals. (Otherwise, it usually page faults inside swi_net_next()) Could somebody explain how this can happen (i thought i would panic and say ``stack oveflow'') and how this can be avoided? Thanks in forward! Bye! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 10:21: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 6530637B40C; Tue, 7 Aug 2001 10:21:22 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f77HLBb33221; Tue, 7 Aug 2001 10:21:11 -0700 (PDT) (envelope-from dillon) Date: Tue, 7 Aug 2001 10:21:11 -0700 (PDT) From: Matt Dillon Message-Id: <200108071721.f77HLBb33221@earth.backplane.com> To: Garance A Drosihn Cc: Terry Lambert , Mike Smith , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <200108071655.f77Gt9M32808@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 :I'd agree that is a specialized situation, one which wouldn't :be critical to many freebsd users. Is Terry right that the :current strategy will "lock us into virtual wire mode", in :some way which means that this specialized situation CANNOT :be handled? : :(it would be fine if it were "handled" via some specialized :kernel option, imo. I'm just wondering what the limitations :are. I do not mean to imply we should follow some different :strategy here, I'm just wondering...) : :-- :Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu In -current there is nothing preventing us from wiring interrupt *threads* to cpus. Wiring the actual interrupts themselves might or might not yield a performance improvement beyond that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 10:21:35 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 EDE4A37B40E for ; Tue, 7 Aug 2001 10:21:25 -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 MAA70983; Tue, 7 Aug 2001 12:33:32 -0700 (PDT) Date: Tue, 7 Aug 2001 12:33:31 -0700 (PDT) From: Julian Elischer To: "Koster, K.J." Cc: "'les@safety.net'" , freebsd-hackers@FreeBSD.ORG Subject: RE: dmesg behaviour In-Reply-To: <59063B5B4D98D311BC0D0001FA7E452205FD9E8C@l04.research.kpn.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 this is a wonderful feature that has saved my butt many times (working in the kernel it's REALLY nice to have the last panic message in the dmesg buffer.) learn to love it.. :-) On Tue, 7 Aug 2001, Koster, K.J. wrote: > Dear, > > > > > On the supermicro > > systems, we may see the information from the last 3 boots! I see the > > lines: > > > > syncing disks... done > > Rebooting... > > > > and then we go right into the next boot. At present, one of > > the machines shows all the detail from 2.75 reboots. > > > > How and why is it doing this, and how do I make it stop? > > > FWIW, FreeBSD/alpha also exhibits this behaviour. Perhaps it's better to > adapt your tools to cope to improve their portability between > FreeBSD-supported architectures? > > Kees Jan > > ===================================================== > You can't have everything. Where would you put it? > [Steven Wright] > > 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 7 10:32: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from safety.net (ns3.safety.net [216.200.162.38]) by hub.freebsd.org (Postfix) with ESMTP id A4EE637B43E for ; Tue, 7 Aug 2001 10:31:53 -0700 (PDT) (envelope-from les@safety.net) Received: (from les@localhost) by safety.net (8.9.3/8.9.3) id KAA91767; Tue, 7 Aug 2001 10:31:40 -0700 (MST) (envelope-from les) From: Les Biffle Message-Id: <200108071731.KAA91767@safety.net> Subject: Re: dmesg behaviour In-Reply-To: from Julian Elischer at "Aug 7, 2001 12:33:31 pm" To: julian@elischer.org (Julian Elischer) Date: Tue, 7 Aug 2001 10:31:40 -0700 (MST) Cc: K.J.Koster@kpn.com (Koster K.J.), les@safety.net ('les@safety.net'), freebsd-hackers@FreeBSD.ORG Reply-To: les@safety.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > this is a wonderful feature that has saved my butt many times > (working in the kernel it's REALLY nice to have > the last panic message in the dmesg buffer.) > learn to love it.. :-) I can see the benefits. I will re-write the programs and scripts that eat the dmesg output to look for the last boot, but I'm concerned that the behavior is different on different platforms. I really hate mysterious platform differences. Thanks, -Les -- Les Biffle Community Service... Just Say NO! (480) 585-4099 les@safety.net http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 10:36:42 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 4B5AA37B411 for ; Tue, 7 Aug 2001 10:36:38 -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 f77HaBQ34372; Tue, 7 Aug 2001 19:36:12 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: les@safety.net Cc: julian@elischer.org (Julian Elischer), K.J.Koster@kpn.com (Koster K.J.), freebsd-hackers@FreeBSD.ORG Subject: Re: dmesg behaviour In-Reply-To: Your message of "Tue, 07 Aug 2001 10:31:40 PDT." <200108071731.KAA91767@safety.net> Date: Tue, 07 Aug 2001 19:36:11 +0200 Message-ID: <34370.997205771@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 <200108071731.KAA91767@safety.net>, Les Biffle writes: >> this is a wonderful feature that has saved my butt many times >> (working in the kernel it's REALLY nice to have >> the last panic message in the dmesg buffer.) >> learn to love it.. :-) > >I can see the benefits. I will re-write the programs and scripts that >eat the dmesg output to look for the last boot, but I'm concerned that >the behavior is different on different platforms. I really hate mysterious >platform differences. The console-log code is machine-independent apart from the initial allocation of the space, so don't expect differences in this area. -- 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 7 10:41:12 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 1E3E537B403; Tue, 7 Aug 2001 10:41:05 -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 MAA71075; Tue, 7 Aug 2001 12:55:21 -0700 (PDT) Date: Tue, 7 Aug 2001 12:55:20 -0700 (PDT) From: Julian Elischer To: "Semen A. Ustimenko" Cc: freebsd-hackers@FreeBSD.org Subject: Re: Kernel stack size 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 the kernel stack is a VERY LIMITED resource basically you have about 4 or 5 Kbytes per process. if you overflow it you write over your signal information.. you should MALLOC space and use a pointer to it.. On Wed, 8 Aug 2001, Semen A. Ustimenko wrote: > Hi! > > I'm developing some code running in kernel that use a lot of stack. And it > seems i run into stack overflow. This results in some proc structure > related parts overwrite (particulary p->p_stats->p_timer[ITIMER_PROF]) and > unexpected signals. (Otherwise, it usually page faults inside > swi_net_next()) > > Could somebody explain how this can happen (i thought i would panic and > say ``stack oveflow'') and how this can be avoided? > > Thanks in forward! > > Bye! > > > 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 7 10:41:20 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 3E2FA37B40A for ; Tue, 7 Aug 2001 10:41:16 -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 MAA71067; Tue, 7 Aug 2001 12:53:39 -0700 (PDT) Date: Tue, 7 Aug 2001 12:53:39 -0700 (PDT) From: Julian Elischer To: Les Biffle Cc: "Koster K.J." , freebsd-hackers@FreeBSD.ORG Subject: Re: dmesg behaviour In-Reply-To: <200108071731.KAA91767@safety.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 sorry if that came across a bit rough... I just know that I LOVE that feature. (you don't get it on machines that clear ram between reboots) On Tue, 7 Aug 2001, Les Biffle wrote: > > this is a wonderful feature that has saved my butt many times > > (working in the kernel it's REALLY nice to have > > the last panic message in the dmesg buffer.) > > learn to love it.. :-) > > I can see the benefits. I will re-write the programs and scripts that > eat the dmesg output to look for the last boot, but I'm concerned that > the behavior is different on different platforms. I really hate mysterious > platform differences. > > Thanks, > > -Les > > -- > Les Biffle Community Service... Just Say NO! > (480) 585-4099 les@safety.net http://www.les.safety.net/ > Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 10:44:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from erasmus.off.net (erasmus.off.net [64.39.30.25]) by hub.freebsd.org (Postfix) with ESMTP id 48BF937B409; Tue, 7 Aug 2001 10:44:36 -0700 (PDT) (envelope-from zab@erasmus.off.net) Received: by erasmus.off.net (Postfix, from userid 928) id 055BC5FF38; Tue, 7 Aug 2001 17:44:37 +0000 (/etc/localtime) Date: Tue, 7 Aug 2001 13:44:37 -0400 From: Zach Brown To: Terry Lambert Cc: Mike Smith , Matt Dillon , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time Message-ID: <20010807134436.B20259@erasmus.off.net> References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B6FB0AE.8D40EF5D@mindspring.com>; from tlambert2@mindspring.com on Tue, Aug 07, 2001 at 02:11:10AM -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 > That Microsoft demonstrated that wiring down interrupts > to a particular CPU was a good idea, and kicked both Linux' > and FreeBSD's butt in the test at ZD Labs? No, Terry, this is not what was demonstrated by those tests. Will this myth never die? Do Mike and I have to write up a nice white paper? :) The environment was ridigly specified: quad cpu box, four eepro 100mb interfaces, and a _heavy_ load of short lived connections fetching static cached content. The test was clearly designed to stress concurrency in the network stack, with heavy low latency interrupt load. Neither Linux nor FreeBSD could do this well at the time. There was a service pack issed a few months before the test that 'threaded' NT's stack.. It was not a mistake that the rules of the tests forbid doing the sane thing and running on a system with a single very fast cpu, lots of mem, and gigabit interface with an actual published interface for coalescing interrupts. That would have performed better and been cheaper. Thats what pisses me off about the tests to this day. The problem people are faced with is is "how do I serve this static content reliably and cheaply", not, "what OS should I serve my content with, now that I've bought this ridiculous machine?". Its sad that people consistently insist on drawing insane conclusions from these benchmark events. -- zach To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 10:59: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ntlg.sibnet.ru (dns.sibnet.ru [217.70.96.34]) by hub.freebsd.org (Postfix) with ESMTP id D399937B401 for ; Tue, 7 Aug 2001 10:59:02 -0700 (PDT) (envelope-from semenu@FreeBSD.org) Received: from tlg5-ppp59.sibnet.ru (tlg5-ppp59.sibnet.ru [217.70.97.60]) by ntlg.sibnet.ru (8.9.3+Sun/8.9.3) with ESMTP id VAA14210; Tue, 7 Aug 2001 21:58:56 +0400 (MSD) Date: Wed, 8 Aug 2001 00:58:54 +0600 (GMT+6) From: "Semen A. Ustimenko" X-Sender: semenu@default To: Julian Elischer Cc: freebsd-hackers@FreeBSD.org Subject: Re: Kernel stack size 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 Hi! Thanks for light speed response! On Tue, 7 Aug 2001, Julian Elischer wrote: > the kernel stack is a VERY LIMITED resource > basically you have about 4 or 5 Kbytes per process. Oops... And there is no hope to enlarge it? > if you overflow it you write over your signal information.. > That's what i'm seeing. SIGPROF, particulary. > you should MALLOC space and use a pointer to it.. > But this is loss of speed, isn't it? Bye! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 11:14:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 5095A37B40A; Tue, 7 Aug 2001 11:14:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.105.118.Dial1.SanJose1.Level3.net [209.244.105.118]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA29356; Tue, 7 Aug 2001 11:14:25 -0700 (PDT) Message-ID: <3B703029.2BB6D25A@mindspring.com> Date: Tue, 07 Aug 2001 11:15:05 -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: Matt Dillon Cc: Mike Smith , Zhihui Zhang , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <200108071655.f77Gt9M32808@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 Dillon wrote: > :What "this", exactly? > : > :That "virtual wire" mode is actually a bad idea for some > :applications -- specifically, high speed networking with > :multiple gigabit ethernet cards? > > All the cpu's don't get the interrupt, only one does. I think that you will end up taking an IPI (Inter Processor Interrupt) to shoot down the cache line during an invalidate cycle, when moving an interrupt processing thread from one CPU to another. For multiple high speed interfaces (disk or network; doesn't matter), you will end up burining a *lot* of time, without a lockdown. You might be able to avoid this by doing some of the tricks I've discussed with Alfred to ensure that there is no lock contention in the non-migratory case for KSEs (or kernel interrupt threads) to handle per CPU scheduling, but I think that the interrupt masking will end up being very hard to manage, and you will get the same effect as locking the interrupt to a particular CPU... if you asre lucky. Any case which _did_ invoke a lock and resulted in contention would require at least a barrier instruction; I guess you could do it in a non-cacheable page to avoid the TLB interaction, and another IPI for an update or invalidate cycle for the lock, but then you are limited to memory speed, which is getting down to around a factor of 10 (133MHz) slower than CPU speed, these days, and that's actually one heck of a stall hit to take. > :That Microsoft demonstrated that wiring down interrupts > :to a particular CPU was a good idea, and kicked both Linux' > :and FreeBSD's butt in the test at ZD Labs? > > Well, if you happen to have four NICs and four CPUs, and > you are running them all full bore, I would say that > wiring the NICs to the CPUs would be a good idea. That > seems like a rather specialized situation, though. I don't think so. These days, interrupt overhead can come from many places, including intentional denial of service attacks. If you have an extra box around, I'd suggest that you install QLinux, and benchmark it side by side against FreeBSD, under an extreme load, and watch the FreeBSD system's performance fall off when interrupt overhead becomes so high that NETISR effectively never gets a chance to run. I also suggest using 100Base-T cards, since the interrupt coelescing on Gigabit cards could prevent you from observing the livelock from interrupt overload, unless you could load your machine to full wire speed (~950Mbits/S) so that your PCI bus transfer rate becomes a barrier. I know you were involved in some of the performance tuning that was attempted immediately after the ZD Labs tests, so I know you know this was a real issue; I think it still is. -- 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 7 11:21: 3 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 7081D37B40C; Tue, 7 Aug 2001 11:20:57 -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 NAA71224; Tue, 7 Aug 2001 13:29:25 -0700 (PDT) Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT) From: Julian Elischer To: "Semen A. Ustimenko" Cc: freebsd-hackers@FreeBSD.org Subject: Re: Kernel stack size 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 Wed, 8 Aug 2001, Semen A. Ustimenko wrote: > Hi! Thanks for light speed response! > > On Tue, 7 Aug 2001, Julian Elischer wrote: > > > the kernel stack is a VERY LIMITED resource > > basically you have about 4 or 5 Kbytes per process. > Oops... And there is no hope to enlarge it? none really. that's the way it is in all kernels.. The kernel is a very limited environment. > > > if you overflow it you write over your signal information.. > > > That's what i'm seeing. SIGPROF, particulary. > > > you should MALLOC space and use a pointer to it.. > > > But this is loss of speed, isn't it? a little but maybe not as much as you think.. malloc is pretty quick. If you are doing it a lot, you might even consider caching the memory blocks.. > > Bye! > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 11:37:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 3749737B410; Tue, 7 Aug 2001 11:37:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.105.118.Dial1.SanJose1.Level3.net [209.244.105.118]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA09771; Tue, 7 Aug 2001 11:37:17 -0700 (PDT) Message-ID: <3B703585.CE87BBD3@mindspring.com> Date: Tue, 07 Aug 2001 11:37:57 -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: Zach Brown Cc: Mike Smith , Matt Dillon , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <20010807134436.B20259@erasmus.off.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Zach Brown wrote: > > That Microsoft demonstrated that wiring down interrupts > > to a particular CPU was a good idea, and kicked both Linux' > > and FreeBSD's butt in the test at ZD Labs? > > No, Terry, this is not what was demonstrated by those tests. Will this > myth never die? Do Mike and I have to write up a nice white paper? :) That would be nice, actually. > > The environment was ridigly specified: quad cpu box, four eepro 100mb > interfaces, and a _heavy_ load of short lived connections fetching static > cached content. The test was clearly designed to stress concurrency in > the network stack, with heavy low latency interrupt load. Neither Linux > nor FreeBSD could do this well at the time. There was a service pack > issed a few months before the test that 'threaded' NT's stack.. > > It was not a mistake that the rules of the tests forbid doing the sane > thing and running on a system with a single very fast cpu, lots of mem, > and gigabit interface with an actual published interface for coalescing > interrupts. That would have performed better and been cheaper. I have soft interrupt coelescing changes for most FreeBSD drivers written by Bill Paul; the operation is trivial, and Bill has structured his drivers well for doing that sort of thing. I personally don't think the test was unfair; it seems to me to be representative of most web traffic, which averages 8k a page for most static content, according to published studies. > Thats what pisses me off about the tests to this day. The problem > people are faced with is is "how do I serve this static content > reliably and cheaply", not, "what OS should I serve my content > with, now that I've bought this ridiculous machine?". 8-) 8-). > Its sad that people consistently insist on drawing insane > conclusions from these benchmark events. I think that concurrency in the TCP stack is something that needs to be addressed; I'm glad they ran the benchmark, if only for that. Even if we both agree on the conclusions, agreeing isn't going to change people's perceptions, but beating them on their terms _will_, so it's a worthwhile pursuit. I happen to agree that their test indicated some shortcomings in the OS designs; regardless of whether we think they were carefully chosen to specifically emphasize those shortcomings, it doesn't change the fact that they are shortcomings. There's no use crying over spilt milk: the question is what can be done about it, besides trying to deny the validity of the tests. -- 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 7 11:44: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 34E6537B40F; Tue, 7 Aug 2001 11:44:03 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.105.118.Dial1.SanJose1.Level3.net [209.244.105.118]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA17157; Tue, 7 Aug 2001 11:43:59 -0700 (PDT) Message-ID: <3B703717.4A50139A@mindspring.com> Date: Tue, 07 Aug 2001 11:44:39 -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: Julian Elischer Cc: "Semen A. Ustimenko" , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel stack size References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > the kernel stack is a VERY LIMITED resource > basically you have about 4 or 5 Kbytes per process. > if you overflow it you write over your signal information.. > > you should MALLOC space and use a pointer to it.. Would adding an unmapped or read-only guard page be unreasonable? The only thing I could see it doing would be panic'ing, so it's not like it'd be possible to dump the process, without handling the double fault and hoping it doesn't go over 4k of overage (or you'd need 2...N guard pages). -- 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 7 11:46:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by hub.freebsd.org (Postfix) with ESMTP id 83D8F37B409 for ; Tue, 7 Aug 2001 11:46:06 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 3E5F338CC5 for ; Tue, 7 Aug 2001 15:45:57 -0300 (EST) Received: (qmail 6790 invoked by uid 0); 7 Aug 2001 18:45:05 -0000 Received: from duckman.distro.conectiva (HELO duckman.conectiva.com.br) (root@10.0.17.2) by burns.conectiva with SMTP; 7 Aug 2001 18:45:05 -0000 Received: from localhost (riel@localhost) by duckman.conectiva.com.br (8.11.4/8.11.3) with ESMTP id f77IjuW05846; Tue, 7 Aug 2001 15:45:56 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Tue, 7 Aug 2001 15:45:56 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Terry Lambert Cc: Matt Dillon , Mike Smith , Zhihui Zhang , Subject: Re: Allocate a page at interrupt time In-Reply-To: <3B703029.2BB6D25A@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, 7 Aug 2001, Terry Lambert wrote: > Matt Dillon wrote: > > All the cpu's don't get the interrupt, only one does. > > I think that you will end up taking an IPI (Inter Processor > Interrupt) to shoot down the cache line during an invalidate > cycle, when moving an interrupt processing thread from one > CPU to another. You have a lot of fantasy today. You may want to consider reading one of the white papers you referred us to with so much enthusiasm and trying again later ;) > > Well, if you happen to have four NICs and four CPUs, and > > you are running them all full bore, I would say that > > wiring the NICs to the CPUs would be a good idea. That > > seems like a rather specialized situation, though. > > I don't think so. These days, interrupt overhead can come > from many places, Exactly. You never know where your interrupts come from, so wiring them in a fixed setup really isn't going to do you much good in the generic case. Now if you want to optimise your source code for something like a Mindcraft "benchmark" ... regards, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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 7 11:51:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f156.pav2.hotmail.com [64.4.37.156]) by hub.freebsd.org (Postfix) with ESMTP id D56D837B401; Tue, 7 Aug 2001 11:51:26 -0700 (PDT) (envelope-from weiguang_shi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 Aug 2001 11:51:26 -0700 Received: from 129.128.29.128 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 07 Aug 2001 18:51:26 GMT X-Originating-IP: [129.128.29.128] From: "Weiguang SHI" To: julian@elischer.org, semenu@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: Kernel stack size Date: Tue, 07 Aug 2001 12:51:26 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Aug 2001 18:51:26.0851 (UTC) FILETIME=[F662A530:01C11F71] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >From: Julian Elischer >To: "Semen A. Ustimenko" >CC: freebsd-hackers@FreeBSD.org >Subject: Re: Kernel stack size >Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT) > > > >On Wed, 8 Aug 2001, Semen A. Ustimenko wrote: > > > Hi! Thanks for light speed response! > > > > On Tue, 7 Aug 2001, Julian Elischer wrote: > > > > > the kernel stack is a VERY LIMITED resource > > > basically you have about 4 or 5 Kbytes per process. > > Oops... And there is no hope to enlarge it? > >none really. >that's the way it is in all kernels.. >The kernel is a very limited environment. How about just changing UPAGES to n (n>2)? Weiguang _________________________________________________________________ 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 Tue Aug 7 12:19: 8 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 9E84137B401; Tue, 7 Aug 2001 12:19:02 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f77JJ1d35789; Tue, 7 Aug 2001 12:19:01 -0700 (PDT) (envelope-from dillon) Date: Tue, 7 Aug 2001 12:19:01 -0700 (PDT) From: Matt Dillon Message-Id: <200108071919.f77JJ1d35789@earth.backplane.com> To: Terry Lambert Cc: Mike Smith , Zhihui Zhang , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <200108071655.f77Gt9M32808@earth.backplane.com> <3B703029.2BB6D25A@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :Matt Dillon wrote: :> :What "this", exactly? :> : :> :That "virtual wire" mode is actually a bad idea for some :> :applications -- specifically, high speed networking with :> :multiple gigabit ethernet cards? :> :> All the cpu's don't get the interrupt, only one does. : :I think that you will end up taking an IPI (Inter Processor :Interrupt) to shoot down the cache line during an invalidate :cycle, when moving an interrupt processing thread from one :CPU to another. For multiple high speed interfaces (disk or :network; doesn't matter), you will end up burining a *lot* :of time, without a lockdown. Cache line invalidation does not require an IPI. TLB shootdowns require IPIs. TLB shootdowns are unrelated to interrupt threads, they only occur when shared mmu mappings change. Cache line invalidation can waste cpu cycles -- when cache mastership changes occur between cpus due to threads being switched between cpus. I consider this a serious problem in -current. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 12:42:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from green.postal.net (adsl-208-190-118-113.dsl.hstntx.swbell.net [208.190.118.113]) by hub.freebsd.org (Postfix) with SMTP id D938737B405 for ; Tue, 7 Aug 2001 12:42:07 -0700 (PDT) (envelope-from emj@postal.net) Received: (qmail 18285 invoked from network); 7 Aug 2001 19:42:03 -0000 Received: from cp562536-a.alngtn1.va.home.com (HELO postal.net) (emj@65.1.249.48) by adsl-208-190-118-113.dsl.hstntx.swbell.net with SMTP TLS RC4-MD5; 7 Aug 2001 19:42:03 -0000 Message-ID: <3B7043BC.39926AD8@postal.net> Date: Tue, 07 Aug 2001 15:38:36 -0400 From: "Eric M. Johnston" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: freebsd-hackers Subject: Re: Linksys WDT11/WPC11 Combo References: <3B6DF2F2.9080302@nettek-llc.com> Content-Type: multipart/mixed; boundary="------------030FF1D367CD8E619FBEF092" Sender: owner-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. --------------030FF1D367CD8E619FBEF092 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, Here's a patch I did against -STABLE circa mid-June. It probably won't apply cleanly today -- I think the 2x MAC address read has been MFC'd. Pretty minor changes, though; it works great for me. Enjoy, Eric Steve Logue wrote: > > Sorry if this is a duplicate.... > > Hello, > > Does anyone have any patches for preliminary support of the Linksys > WDT11/WPC11 wireless ethernet combo? The WDT card uses the PLX PCI9052 > chipset and shows up under -STABLE's dmesg as: > > pci0: (vendor=0x16ab, dev=0x1102) at 19.0 irq 12 > > With what I have been reading so far on the PLX thread, I appear to have > a different dev number. Most people have talked about dev=1101, but I > have dev=1102. Is this a new rev of the board? How can I get this > working? > > Patches for -CURRENT or -STABLE would be appreciated. > > -STEVEl > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message --------------030FF1D367CD8E619FBEF092 Content-Type: text/plain; charset=us-ascii; name="wi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="wi.patch" --- share/man/man4/wi.save Sun Jun 10 06:13:04 2001 +++ share/man/man4/wi.4 Sun Jun 10 06:09:01 2001 @@ -53,6 +53,12 @@ Both the original 2Mbps WaveLAN/IEEE cards and the newer 6Mbps WaveLAN/IEEE Turbo adapters are supported. .Pp +Additionally, the +.Nm +driver supports PCI adapters for the cards based PLX Techology's PCI 9052, +such as the Linksys WDT11 Wireless PCI Adapter which works in conjunction +with the WPC11 Wireless Network PC Card. +.Pp The core of the WaveLAN/IEEE is the Lucent Hermes controller. All host/device interaction is via programmed I/O with the Hermes. --- sys/i386/isa/if_wi.save Sat Jun 9 23:51:31 2001 +++ sys/i386/isa/if_wi.c Sun Jun 10 06:31:10 2001 @@ -230,6 +230,7 @@ wi_pci_probe(dev) struct wi_softc *sc; sc = device_get_softc(dev); + /* XXX Getting a little unwieldy... */ if ((pci_get_vendor(dev) == WI_PCI_VENDOR_EUMITCOM) && (pci_get_device(dev) == WI_PCI_DEVICE_PRISM2STA)) { sc->wi_prism2 = 1; @@ -237,6 +238,20 @@ wi_pci_probe(dev) "PRISM2STA PCI WaveLAN/IEEE 802.11"); return (0); } + if ((pci_get_vendor(dev) == WI_PCI_VENDOR_LINKSYS) && + (pci_get_device(dev) == WI_PCI_DEVICE_WDT11)) { + sc->wi_prism2 = 1; + device_set_desc(dev, + "Linksys WDT11 Wireless PCI Adapter"); + return (0); + } + if ((pci_get_vendor(dev) == WI_PCI_VENDOR_GLOBALSUN) && + (pci_get_device(dev) == WI_PCI_DEVICE_GL24110P)) { + sc->wi_prism2 = 1; + device_set_desc(dev, + "Global Sun GL24110P Wireless PCI Adapter"); + return (0); + } return(ENXIO); } @@ -399,9 +414,15 @@ wi_generic_attach(device_t dev) /* Reset the NIC. */ wi_reset(sc); - /* Read the station address. */ + /* + * Read the station address. + * And do it twice. I've seen PRISM-based cards that return + * an error when trying to read it the first time, which causes + * the probe to fail. + */ mac.wi_type = WI_RID_MAC_NODE; mac.wi_len = 4; + wi_read_record(sc, (struct wi_ltv_gen *)&mac); if ((error = wi_read_record(sc, (struct wi_ltv_gen *)&mac)) != 0) { device_printf(dev, "mac read failed %d\n", error); wi_free(dev); --- sys/i386/isa/if_wireg.save Sat Jun 9 23:51:41 2001 +++ sys/i386/isa/if_wireg.h Sun Jun 10 06:27:17 2001 @@ -147,7 +147,12 @@ struct wi_softc { #define WI_PCI_IORES 0x1C #define WI_PCI_VENDOR_EUMITCOM 0x1638 -#define WI_PCI_DEVICE_PRISM2STA 0x1100 +#define WI_PCI_DEVICE_PRISM2STA 0x1100 /* Eumitcom PCI WL11000 */ +#define WI_PCI_VENDOR_LINKSYS 0x16AB +#define WI_PCI_DEVICE_WDT11 0x1102 /* Linksys PCI WPC11 */ +#define WI_PCI_VENDOR_GLOBALSUN 0x16AB +#define WI_PCI_DEVICE_GL24110P 0x1101 /* Global Sun GL24110P */ + #define WI_HFA384X_SWSUPPORT0_OFF 0x28 #define WI_PRISM2STA_MAGIC 0x4A2D --------------030FF1D367CD8E619FBEF092-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 12:51: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id A210B37B414; Tue, 7 Aug 2001 12:50:57 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f77JtAk50190; Tue, 7 Aug 2001 15:55:10 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 7 Aug 2001 15:55:10 -0400 From: Bosko Milekic To: Matt Dillon Cc: Terry Lambert , Mike Smith , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Message-ID: <20010807155510.A50114@technokratis.com> References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <200108071655.f77Gt9M32808@earth.backplane.com> <3B703029.2BB6D25A@mindspring.com> <200108071919.f77JJ1d35789@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: <200108071919.f77JJ1d35789@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Aug 07, 2001 at 12:19:01PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 07, 2001 at 12:19:01PM -0700, Matt Dillon wrote: > Cache line invalidation does not require an IPI. TLB > shootdowns require IPIs. TLB shootdowns are unrelated to > interrupt threads, they only occur when shared mmu mappings > change. Cache line invalidation can waste cpu cycles -- > when cache mastership changes occur between cpus due to > threads being switched between cpus. I consider this a > serious problem in -current. I don't think it's fair to consider this a serious problem seeing as how, as far as I'm aware, we've intended to eventually introduce code that will favor keeping threads running on one CPU on that same CPU as long as it is reasonable to do so (which should be most of the time). I think after briefly discussing with Alfred on IRC that Alfred has some CPU affinity patches on the way, but I'm not sure if they address thread scheduling with the above intent in mind or if they merely introduce an _interface_ to bind a thread to a single CPU. > -Matt -- 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 Tue Aug 7 13: 1: 5 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 D5DE037B40C; Tue, 7 Aug 2001 13:00:59 -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 PAA71598; Tue, 7 Aug 2001 15:07:46 -0700 (PDT) Date: Tue, 7 Aug 2001 15:07:45 -0700 (PDT) From: Julian Elischer To: Weiguang SHI Cc: semenu@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Kernel stack size 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 yes you could do that but N is still goin gto be small when compared to teh size of a userland stack, and all upages come out of a KVM object which is limitted. When we get threads, we have to be able to have a hundred stacks per process if things get silly. Actually in teh KSE kernel I'm working on UPAGES is defined as (UAREA_PAGES+KSTATCK_PAGES) so increasing KSTACK_PAGES (presently 1) is what you would want to do.. it's still bad practice (particularly on 4.x) to put a lot of stuff on the kernel stack. Also, remember that if you are writing a device driver, the interrupt half of your driver will not always run on the same stack as the top half, so things that are passed between them can't be stored there.. (not to mention if the process gets swapped out) On Tue, 7 Aug 2001, Weiguang SHI wrote: > > > > >From: Julian Elischer > >To: "Semen A. Ustimenko" > >CC: freebsd-hackers@FreeBSD.org > >Subject: Re: Kernel stack size > >Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT) > > > > > > > >On Wed, 8 Aug 2001, Semen A. Ustimenko wrote: > > > > > Hi! Thanks for light speed response! > > > > > > On Tue, 7 Aug 2001, Julian Elischer wrote: > > > > > > > the kernel stack is a VERY LIMITED resource > > > > basically you have about 4 or 5 Kbytes per process. > > > Oops... And there is no hope to enlarge it? > > > >none really. > >that's the way it is in all kernels.. > >The kernel is a very limited environment. > > How about just changing UPAGES to n (n>2)? > > Weiguang > > _________________________________________________________________ > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 13: 9: 4 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 A189037B403; Tue, 7 Aug 2001 13:09:00 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 6678181D01; Tue, 7 Aug 2001 15:08:50 -0500 (CDT) Date: Tue, 7 Aug 2001 15:08:50 -0500 From: Alfred Perlstein To: Bosko Milekic Cc: Matt Dillon , Terry Lambert , Mike Smith , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Message-ID: <20010807150850.V85642@elvis.mu.org> References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <200108071655.f77Gt9M32808@earth.backplane.com> <3B703029.2BB6D25A@mindspring.com> <200108071919.f77JJ1d35789@earth.backplane.com> <20010807155510.A50114@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010807155510.A50114@technokratis.com>; from bmilekic@technokratis.com on Tue, Aug 07, 2001 at 03:55:10PM -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 * Bosko Milekic [010807 14:51] wrote: > > On Tue, Aug 07, 2001 at 12:19:01PM -0700, Matt Dillon wrote: > > Cache line invalidation does not require an IPI. TLB > > shootdowns require IPIs. TLB shootdowns are unrelated to > > interrupt threads, they only occur when shared mmu mappings > > change. Cache line invalidation can waste cpu cycles -- > > when cache mastership changes occur between cpus due to > > threads being switched between cpus. I consider this a > > serious problem in -current. > > I don't think it's fair to consider this a serious problem seeing as > how, as far as I'm aware, we've intended to eventually introduce code that will > favor keeping threads running on one CPU on that same CPU as long as it is > reasonable to do so (which should be most of the time). > I think after briefly discussing with Alfred on IRC that Alfred has > some CPU affinity patches on the way, but I'm not sure if they address > thread scheduling with the above intent in mind or if they merely introduce > an _interface_ to bind a thread to a single CPU. They do both. :) You can bind a process to a runqueue _and_ at the same time as long as a process on another CPU doesn't have a much higher priority we'll take from our local pool. Basically we give processes that last ran on our own CPU a false priority boost. http://people.freebsd.org/~alfred/bind_cpu.diff + cpu = PCPU_GET(cpuid); + pricpu = runq_findbit(&runqcpu[cpu]); + pri = runq_findbit(rq); + CTR2(KTR_RUNQ, "runq_choose: pri=%d cpupri=%d", pri, pricpu); + if (pricpu != -1 && (pricpu < pri || pri == -1)) { + pri = pricpu; + rqh = &runqcpu[cpu].rq_queues[pri]; + } else if (pri != -1) { + rqh = &rq->rq_queues[pri]; + } else { + CTR1(KTR_RUNQ, "runq_choose: idleproc pri=%d", pri); + return (PCPU_GET(idleproc)); + } + p = TAILQ_FIRST(rqh); Actually I think this patch is stale, it doesn't have the priority boost, but basically you can put it in the if (pricpu != -1 && (pricpu < pri || pri == -1)) { clause sort of like this: if (pricpu != -1 && (pricpu - FUDGE < pri || pri == -1)) { Where FUDGE is the priority boost you want to give local processes. -- -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 7 14:15:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 952B137B624 for ; Tue, 7 Aug 2001 14:15:27 -0700 (PDT) (envelope-from float@firedrake.org) Received: from float by dayspring.firedrake.org with local (Exim 3.22 #1 (Debian)) id 15UEBx-0006Wc-00; Tue, 07 Aug 2001 22:15:09 +0100 Date: Tue, 7 Aug 2001 22:15:09 +0100 To: Terry Lambert Cc: freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time Message-ID: <20010807221509.A24999@firedrake.org> References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B6FB0AE.8D40EF5D@mindspring.com> User-Agent: Mutt/1.3.18i From: void Sender: owner-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 07, 2001 at 02:11:10AM -0700, Terry Lambert wrote: > > Can you name one SMP OS implementation that uses an > "interrupt threads" approach that doesn't hit a scaling > wall at 4 (or fewer) CPUs, due to heavier weight thread > context switch overhead? Solaris, if I remember my Vahalia book correctly (isn't that a favorite of yours?). -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 14:40:58 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 DE3F837B414 for ; Tue, 7 Aug 2001 14:40:49 -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 QAA71915 for ; Tue, 7 Aug 2001 16:42:30 -0700 (PDT) Date: Tue, 7 Aug 2001 16:42:28 -0700 (PDT) From: Julian Elischer To: hackers@freebsd.org Subject: -Stable, apache, ldap and shlibs 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 Who is the expert on apache, modules and shlibs? (I'll go offline to discuss the problem if I can find an appropriate person.. (can't get ldap module to work with apache under freebsd.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 15:30:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 6F6C537B406 for ; Tue, 7 Aug 2001 15:30:13 -0700 (PDT) (envelope-from crossd@spigot.cs.rpi.edu) Received: from spigot.cs.rpi.edu (spigot.cs.rpi.edu [128.113.96.204]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id SAA72581 for ; Tue, 7 Aug 2001 18:30:12 -0400 (EDT) Message-Id: <200108072230.SAA72581@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: ypserv update Date: Tue, 07 Aug 2001 18:30:12 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok... I have just finished the first step in a rewrite of the hash routines for berkleydb (read-only at this point), and I have ypserv compiled using them. So far so good :). And ypserv uses a _lot_ less CPU resources now. (I have totally removed all of the buffer management code in berkley db, and I am using mmap() exclusively. Still to be done is to impliment R_CURSOR type, that will improve ypserv's performance quite a bit in environments like ours.). If all goes well (no bugs found), I will put this up on my website in source-only form tonight. Maybe be added to ports tonight too. I am eagerly looking for helpers to complete the hash rewrite, and then the rest of berkley DB as well. File format information would be very usefull, the stuff that is included with BDB is lacking. -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 18:39:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.tgegroup.com (unknown [202.108.126.68]) by hub.freebsd.org (Postfix) with ESMTP id 8128C37B40D for ; Tue, 7 Aug 2001 18:39:13 -0700 (PDT) (envelope-from craiglei@pasia.com.cn) Received: from fdsaf ([10.10.26.5]) by mail.tgegroup.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QMG4DHH7; Wed, 8 Aug 2001 09:27:14 +0800 Message-ID: <002001c11fab$19acaca0$051a0a0a@fd.com> From: "craig" To: Cc: Subject: Why page enable in Kernel space? Date: Wed, 8 Aug 2001 09:40:27 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C11FEE.27B782A0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C11FEE.27B782A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SW4gZ2VuZXJhbCBhIGFkZHJlc3MgaW4gYSBwcm9jZXNzIGlzIGp1c3QgYSBsaW5lYXIgYWRkcmVz cyB3aGljaCByZWZlciB0byBwaHlzaWNhbCBhZGRyZXNzIGluZGlyZWN0bHkgDQpieSBwYWdlIGRp cmVjdG9yeS4gIFRoaXMgaXMgcmVhc29uYWJsZSBpbiB1c2VyIHNwYWNlLiBIb3dldmVyIGlzIGl0 IG5lY2Vzc2FyeSB0byBkbyBzdWNoIHRoaW5nIGluIGtlcm5lbD8NCkl0IGlzIHN1cmUgdG8gaGF2 ZSBwZW5hbHR5IHdoZW4gY29udmVydGluZyBhIGxpbmVhciBhZGRyZXNzIHRvIHBoeXNpY2FsIHRo aW5nLiBJcyBpdCB3b3J0aCBkb2luZyBzdWNoDQp0aGluZyBpbiBrZXJuZWwuIA0KDQpJIHRoaW5r IHRoZSBwZXJmb3JtYW5jZSBpcyB0aGUgbW9zdCBpbXBvcnRhbnQgaW4ga2VybmVsLCBvdGhlciB0 aGluZyBpcyBzZWNvbmQuIEkgcmVtZW1iZXIgaW4gDQpsaW51eCBsaW5lYXIgYWRkcmVzcyBpcyBy ZWFsIHBoeXNpY2FsIGFkZHJlc3MgaW4ga2VybmVsIHNwYWNlKGlzIGl0IHRydWU/KS4gV2h5IGZy ZWVic2QgZG9lcyBub3QgZG8gaW4gdGhlIHNhbWUgd2F5Pw0KDQoNCmNyYWlnbGVpDQoNCg== ------=_NextPart_000_001D_01C11FEE.27B782A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5JbiBnZW5lcmFsIGEgYWRk cmVzcyBpbiBhIHByb2Nlc3MgaXMganVzdCBhIGxpbmVhciBhZGRyZXNzIA0Kd2hpY2gmbmJzcDty ZWZlciB0byBwaHlzaWNhbCBhZGRyZXNzIGluZGlyZWN0bHkmbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5ieSBwYWdlIGRpcmVjdG9yeS4mbmJzcDsgVGhpcyBpcyByZWFzb25h YmxlIGluIHVzZXIgc3BhY2UuIA0KSG93ZXZlciBpcyBpdCBuZWNlc3NhcnkgdG8gZG8gc3VjaCB0 aGluZyBpbiBrZXJuZWw/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXQgaXMgc3Vy ZSB0byBoYXZlIHBlbmFsdHkgd2hlbiBjb252ZXJ0aW5nIGEgbGluZWFyIGFkZHJlc3MgdG8gDQpw aHlzaWNhbCB0aGluZy4gSXMgaXQgd29ydGggZG9pbmcgc3VjaDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPnRoaW5nPC9GT05UPjxGT05UIHNpemU9Mj4gaW4ga2VybmVsLiA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5JIHRoaW5rIHRoZSBwZXJmb3JtYW5jZSBpcyB0aGUgbW9zdCBpbXBvcnRhbnQgaW4g a2VybmVsLCBvdGhlciANCnRoaW5nIGlzIHNlY29uZC4gSSByZW1lbWJlciBpbiA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5saW51eCBsaW5lYXIgYWRkcmVzcyBpcyByZWFsIHBoeXNp Y2FsIGFkZHJlc3MgaW4ga2VybmVsIA0Kc3BhY2UoaXMgaXQgdHJ1ZT8pLiBXaHkgZnJlZWJzZCBk b2VzIG5vdCBkbyBpbiB0aGUgc2FtZSB3YXk/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5jcmFpZ2xlaTwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_001D_01C11FEE.27B782A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 18:39:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4DB6E37B420 for ; Tue, 7 Aug 2001 18:39:31 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA75736 for ; Tue, 7 Aug 2001 21:39:29 -0400 (EDT) Message-Id: <200108080139.VAA75736@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: GRRRR (ypserv) Date: Tue, 07 Aug 2001 21:39:29 -0400 From: "David E. Cross" Sender: owner-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 am apparently bug-compatible with the original too, though it took longer to trip over it (and the code runs LOTS faster :)... So probably not tonight. I am going to be placing debugging statements in the code to see if I can figure out where information is being stepped on.) -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 19: 0:51 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 A8F4737B409 for ; Tue, 7 Aug 2001 19:00:45 -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 VAA72735; Tue, 7 Aug 2001 21:10:47 -0700 (PDT) Date: Tue, 7 Aug 2001 21:10:46 -0700 (PDT) From: Julian Elischer To: craig Cc: tlambert2@mindspring.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Why page enable in Kernel space? In-Reply-To: <002001c11fab$19acaca0$051a0a0a@fd.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 Wed, 8 Aug 2001, craig wrote: > In general a address in a process is just a linear address which refer > to physical address indirectly by page directory. This is reasonable > in user space. However is it necessary to do such thing in kernel? It > is sure to have penalty when converting a linear address to physical > thing. Is it worth doing such thing in kernel. > > I think the performance is the most important in kernel, other thing > is second. I remember in linux linear address is real physical address > in kernel space(is it true?). No > Why freebsd does not do in the same way? it wouldn't work.. > > > craiglei > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 19: 1: 3 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 2F5FB37B401 for ; Tue, 7 Aug 2001 19:00:59 -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 VAA72737; Tue, 7 Aug 2001 21:12:55 -0700 (PDT) Date: Tue, 7 Aug 2001 21:12:55 -0700 (PDT) From: Julian Elischer To: craig Cc: tlambert2@mindspring.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Why page enable in Kernel space? In-Reply-To: <002001c11fab$19acaca0$051a0a0a@fd.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 Wed, 8 Aug 2001, craig wrote: > In general a address in a process is just a linear address which refer > to physical address indirectly by page directory. This is reasonable > in user space. However is it necessary to do such thing in kernel? It > is sure to have penalty when converting a linear address to physical > thing. Is it worth doing such thing in kernel. > > I think the performance is the most important in kernel, other thing > is second. I remember in linux linear address is real physical address > in kernel space(is it true?). Why freebsd does not do in the same way? To add a bit more.. the kernel uses 4MB of linear physical memory for it's text. (this saves a lot of TLBs but still requires paging to be on. > > > craiglei > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 19:37:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id 22B6F37B401 for ; Tue, 7 Aug 2001 19:37:33 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f782bVc131095; Wed, 8 Aug 2001 11:37:31 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f782bVK286100; Wed, 8 Aug 2001 11:37:31 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:l503YC1OBQ5fSQr7GAzSfezXKwnAeiU4@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id LAA05281; Wed, 8 Aug 2001 11:47:09 +0900 (JST) Message-Id: <200108080247.LAA05281@zodiac.mech.utsunomiya-u.ac.jp> To: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: dmesg behaviour In-reply-to: Your message of "Tue, 07 Aug 2001 12:53:39 MST." References: Date: Wed, 08 Aug 2001 11:47:08 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As far as I understand, this feature works only if the machine does not clear its memory upon reboot. AT compatibles clear memory during the BIOS POST, thus, we don't see console log from the previous boot on the i386 platform. Kazu >sorry if that came across a bit rough... >I just know that I LOVE that feature. >(you don't get it on machines that clear ram between reboots) > > >On Tue, 7 Aug 2001, Les Biffle wrote: > >> > this is a wonderful feature that has saved my butt many times >> > (working in the kernel it's REALLY nice to have >> > the last panic message in the dmesg buffer.) >> > learn to love it.. :-) >> >> I can see the benefits. I will re-write the programs and scripts that >> eat the dmesg output to look for the last boot, but I'm concerned that >> the behavior is different on different platforms. I really hate mysterious >> platform differences. >> >> Thanks, >> >> -Les >> >> -- >> Les Biffle Community Service... Just Say NO! >> (480) 585-4099 les@safety.net http://www.les.safety.net/ >> Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 21: 4: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 0EB5A37B401 for ; Tue, 7 Aug 2001 21:04:01 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 216FB6ACE4; Wed, 8 Aug 2001 13:34:15 +0930 (CST) Date: Wed, 8 Aug 2001 13:34:14 +0930 From: Greg Lehey To: Terry Lambert Cc: Bosko Milekic , Matt Dillon , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Message-ID: <20010808133414.H78395@wantadilla.lemis.com> References: <200108051955.f75Jtk882156@earth.backplane.com> <3B6F8A6C.B95966B7@mindspring.com> <20010807031832.A46112@technokratis.com> <3B6FADAD.C8CC14C5@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6FADAD.C8CC14C5@mindspring.com>; from tlambert2@mindspring.com on Tue, Aug 07, 2001 at 01:58:21AM -0700 Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-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 Tuesday, 7 August 2001 at 1:58:21 -0700, Terry Lambert wrote: > Bosko Milekic wrote: >>> I keep wondering about the sagicity of running interrupts in >>> threads... it still seems like an incredibly bad idea to me. >>> >>> I guess my major problem with this is that by running in >>> threads, it's made it nearly impossibly to avoid receiver >>> livelock situations, using any of the classical techniques >>> (e.g. Mogul's work, etc.). >> >> References to published works? > > Just do an NCSTRL search on "receiver livelock"; you will get > over 90 papers... > > http://ncstrl.mit.edu/ > > See also the list of participating institutions: > > http://ncstrl.mit.edu/Dienst/UI/2.0/ListPublishers > > It won't be that hard to find... Mogul has "only" published 92 > papers. 8-) So much data, in fact, that you could hide anything behind it. Would you like to be more specific? >>> It also has the unfortunate property of locking us into virtual >>> wire mode, when in fact Microsoft demonstrated that wiring down >>> interrupts to particular CPUs was good practice, in terms of >>> assuring best performance. Specifically, running in virtual >> >> Can you point us at any concrete information that shows >> this? Specifically, without being Microsoft biased (as is most >> "data" published by Microsoft)? -- i.e. preferably third-party >> performance testing that attributes wiring down of interrupts to >> particular CPUs as _the_ performance advantage. > > FreeBSD was tested, along with Linux and NT, by Ziff Davis > Labs, in Foster city, with the participation of Jordan > Hubbard and Mike Smith. You can ask either of them for the > results of the test; only the Linux and NT numbers were > actually released. This was done to provide a non-biased > baseline, in reaction to the Mindcraft benchmarks, where > Linux showed so poorly. They ran quad ethernet cards, with > quad CPUs; the NT drivers wired the cards down to seperate > INT A/B/C/D interrupts, one per CPU. You carefully neglect to point out that this was the old SMP implementation. I think this completely invalidates any point you may have been trying to make. >>> wire mode means that all your CPUs get hit with the interrupt, >>> whereas running with the interrupt bound to a particular CPU >>> reduces the overall overhead. Even what we have today, with >> >> Obviously. > > I mention it because this is the direction FreeBSD appears > to be moving in. Right now, Intel is shipping with seperate > PCI busses; there is one motherboard from their serverworks > division that has 16 seperate PCI busses -- which means that > you can do simultaneous gigabit card DMA to and from memory, > without running into bus contention, so long as the memory is > logically seperate. NT can use this hardware to its full > potential; FreeBSD as it exists, can not, and FreeBSD as it > appears to be heading today (interrupt threads, etc.) seems > to be in the same boat as Linux, et. al.. PCI-X will only > make things worse (8.4 gigabit, burst rate). What do interrupt threads have to do with this? Terry, we've done a lot of thinking about performance implications over the last 2 years, including addressing all of the points that you appear to raise. A lot of it is in the archives. It's quite possible that we've missed something important that you haven't. But if that's the case, we'd like you to state it. All I see is you coming in, waving your hands and shouting generalities which don't really help much. The fact that people are still listening is very much an indication of the hope that you might come up with something useful. But pointing to 92 papers and saying "it's in there [somewhere]" isn't very helpful. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 21: 9:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from new.now.nxt.cn (unknown [61.143.52.235]) by hub.freebsd.org (Postfix) with SMTP id EE72937B40F for ; Tue, 7 Aug 2001 21:09:27 -0700 (PDT) (envelope-from root@now.nxt.cn) Received: (qmail 28001 invoked by uid 99); 9 Mar 2001 13:34:59 -0000 Date: 9 Mar 2001 13:34:59 -0000 Message-ID: <20010309133459.28000.qmail@new.now.nxt.cn> To: freebsd-hackers@freebsd.org Subject: ¡îÓòÃû×¢²á¿Õ¼äÉêÇë¸÷ËÍÈý¸ö´Î¼¶ÓòÃû»¹Ãâ·ÑÊÔÓÃ! From: "ÍøÂçʱ´ú" Reply-To: youko@now.net.cn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ×ð¾´µÄÅóÓÑ£¬ÄúºÃ£¡ ·Ç³£¸ÐлÄúµÄä¯ÀÀ£¬Èç¹ûÄúÕýΪѰÕÒÒ»¸ö¸üºÃµÄISP¶ø·³ÄÕ£¬ÄÇôÎÒÃÇÍøÂçʱ´úhttp://www.now.net.cnΪÄúÌṩÁË×î¼ÑµÄÑ¡Ôñ£¡ ¡î ÓòÃû×¢²á ×¢²áÓòÃûÔùËÍ3¸ö´Î¼¶ÓòÃû(´øVDNS)£¡ ͬʱÉêÇë¿Õ¼äÔÙÔùËÍ3¸ö´Î¼¶ÓòÃû£¡ ¡îÐéÄâÖ÷»ú Ò» ÌضàÓÅ»Ý ·²ÔÚ8.1µ½9.1×¢²áÓòÃûͬʱÉêÇë¿Õ¼äËÍ6¸ö´Î¼¶ÓòÃû£¡µÈÓÚÒ»¸öÓòÃû¾ÍÄÜͬʱ½¨6¸öÍøÕ¾£¡Í¬Ê±¼ÓËÍ15¸öÉÌÓÃÓʼþÕ˺ţ¡ ¶þ ³¬µÍÌØ¼Û 280Ôª£¡Äú¿ÉÒÔÁ¢¿ÌÓµÓÐÎȶ¨¶ø¿ìËÙµÄ100MÐéÄâÖ÷»ú¿Õ¼ä!»¹ÓÌԥʲôÄØ£¬¸Ï¿ìÐж¯°É£¡ Èý ³¹µ×½â·Å ÏÖÔÚÌ컥¿Æ¼¼µÄASPºÍACCESSÊý¾Ý¿âÈ«Ã濪·Å£¬Ö»Ðè100Ôª¾ÍÈÃÄúµÄÍøÕ¾ÓµÓÐÊý¾Ý¿â¡£ ²¢ÓÐÌṩCGI PERL PHP JSP µÈÒ»Ìå¸ß¼¶¿Õ¼ä.ËùÓпռäʵʱ¿ªÍ¨Ãâ·ÑÊÔÓÃ15Ìì! ¡î¡î"»ðºìÏÄÈÕ¡±Ö÷»úÍйÜÓÅ»Ýì«·çÈ«ÃæµÇ½£¬Ç¿´ó¡¢¸ß±ê×¼µÄµçÐż¶Êý¾ÝÖÐÐÄ»ú·¿£¬¸ß°²È«ÌØÐÔ¡¢¸ß·þÎñ±ê×¼¡¢ ÔÙ¼ÓÉϺÏÀíµÄ¼Û¸ñ£¬Ïò¹ã´ó¿Í»§Ìṩ¸ßÐԼ۱ȵķþÎñ¡£Ïê¼ûhttp://idc.now.net.cn ¡î¡îͬʱÎÒÃÇÏò¹ã´ó¸÷½ì³ÏÕ÷´úÀí£¬ÈȳÀÑûÇëÄú¼ÓÈëÍøÂçʱ´úµÄÒµÎñºÏ×÷ÕóÓª£¬¹²Í¬·ÖÏíÍøÂçʱ´úµÄÅÓ´ó¿Í»§×ÊÔ´¡£ÏêϸÇë·ÃÎÊÎÒÃÇÍøÕ¾¡£ »òÖ±½ÓÁªÏµÎÒÃÇ: ÇñС½ã michelle@now.net.cn ÁÖÏÈÉú youko@now.net.cn¡¡¡¡¡¡ µç»°£º0756-2125583 22216376 ¼¼Êõ²¿£º sanry@now.net.cn youko@now.net.cn 0756--2216376 2139739 »¶Ó­ÖÂÐÅ Today's Network support@now.net.cn »¶Ó­Äú·ÃÎÊÎÒÃǵÄÍøÕ¾ http://www.now.net.cn ÎÒÃÇÒ»Ö±ÒÔרҵ¡¢ÓÅÖÊ¡¢ÁìÏÈΪ×ÚÖ¼£¬ÈȳÏΪÄú·þÎñ£¡ ... ×¢£ºVDNS¿ÉÊÓ»¯ÓòÃû·þÎñÆ÷£¬ÄÜʵÏÖ£Õ£Ò£Ìת·¢¡¢Ö÷»ú£Á¼Ç¼¡¢£Í£ØÓʼþ¼Ç¼¡¢£É£ÐÖ¸Ïò¿ØÖƵȲÙ×÷,¸ü¿ÉÒÔËæÐÄËùÓûµØÔö¼Ó×Ô¼ºµÄ´Î¼¶ÓòÃû£¬°ïÖúÄú½¨Á¢¶à¸öÍøÕ¾£¬Äã¿ÉÒÔÈÃËýÖ¸ÏòÈκοռ䡣 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 21:33:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id E0D8637B403 for ; Tue, 7 Aug 2001 21:33:27 -0700 (PDT) (envelope-from boshea@netapp.com) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f784XMX08248 for ; Tue, 7 Aug 2001 21:33:22 -0700 (PDT) Received: from shaolin.hq.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f784XMm04558 for ; Tue, 7 Aug 2001 21:33:22 -0700 (PDT) Received: (from boshea@localhost) by shaolin.hq.netapp.com (8.9.3/8.9.3) id VAA11999 for freebsd-hackers@freebsd.org; Tue, 7 Aug 2001 21:33:20 -0700 (PDT) (envelope-from boshea) Date: Tue, 7 Aug 2001 21:33:20 -0700 From: "Brian O'Shea" To: freebsd-hackers@freebsd.org Subject: Tuning the 4.1-R kernel for networking Message-ID: <20010807213320.D529@ricochet.net> Reply-To: boshea@ricochet.net Mail-Followup-To: Brian O'Shea , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I am using a PIII 550MHz UP system running FreeBSD 4.1-RELEASE. It has a 3c905B-TX Fast Etherlink XL card. # ifconfig xl0 xl0: flags=8843 mtu 1500 inet 10.34.24.62 netmask 0xfffffc00 broadcast 10.34.27.255 inet6 fe80::2c0:4fff:fe20:3926%xl0 prefixlen 64 scopeid 0x1 ether 00:c0:4f:20:39:26 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX On this machine I run a program which simulates many (~150) simultaneous TCP clients. This is actually a multithreaded Linux binary, and one thread per simulated TCP client is created. After a few seconds the system runs out of mbuf clusters: # netstat -m 3231/3392/6144 mbufs in use (current/peak/max): 1641 mbufs allocated to data 182 mbufs allocated to packet headers 1408 mbufs allocated to socket names and addresses 1536/1536/1536 mbuf clusters in use (current/peak/max) 3920 Kbytes allocated to network (98% in use) 96993 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Also, I see a steady stream of these messages on the console: xl0: no memory for rx list -- packet dropped! >From the xl(4) man page: xl%d: no memory for rx list The driver failed to allocate an mbuf for the receiver ring. Looking at the xl_newbuf() function in the xl driver, there are two places where this message can be generated. It looks like the problem is with the second case where the MCLGET fails, since we are running out of those. /* * Initialize an RX descriptor and attach an MBUF cluster. */ static int xl_newbuf(sc, c) struct xl_softc *sc; struct xl_chain_onefrag *c; { struct mbuf *m_new = NULL; MGETHDR(m_new, M_DONTWAIT, MT_DATA); if (m_new == NULL) { printf("xl%d: no memory for rx list -- " "packet dropped!\n", sc->xl_unit); return(ENOBUFS); } MCLGET(m_new, M_DONTWAIT); if (!(m_new->m_flags & M_EXT)) { printf("xl%d: no memory for rx list -- " "packet dropped!\n", sc->xl_unit); m_freem(m_new); return(ENOBUFS); } m_new->m_len = m_new->m_pkthdr.len = MCLBYTES; /* Force longword alignment for packet payload. */ m_adj(m_new, ETHER_ALIGN); c->xl_mbuf = m_new; c->xl_ptr->xl_frag.xl_addr = vtophys(mtod(m_new, caddr_t)); c->xl_ptr->xl_frag.xl_len = MCLBYTES | XL_LAST_FRAG; c->xl_ptr->xl_status = 0; return(0); } I increased maxusers to 128 (2560 mbuf clusters) and it ran out of mbuf clusters again. Then I increased it to 256 (4608 mbuf clusters), with the same results. I don't have any sense of what is reasonable mbuf cluster usage for the application that I am running, but the system never seems to recover from the condition, which would seem to point to an mbuf cluster leak. Does this sound like a problem with the driver (mbuf cluster leak), or with the way that I have tuned this system? (the kernel config file for this system is attached) I compiled a debug kernel and panicked the system while it was in the state described above, in case that is any use. I don't know how to analyze the crash dump to determine where the problem is. Any suggestions are welcome. Thanks, -brian -- Brian O'Shea --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=SHAOLIN # # SHAOLIN -- Kernel based on the GENERIC configuration file for FreeBSD/i386 # machine i386 cpu I686_CPU ident SHAOLIN maxusers 256 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev options DDB #Enable the kernel debugger device isa device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Sound card support device pcm # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gif 4 # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Ethernet, requires mii device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet --sm4nu43k4a2Rpi4c-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 21:54: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 29CFD37B687 for ; Tue, 7 Aug 2001 21:54:01 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 86379 invoked by uid 1000); 8 Aug 2001 04:53:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Aug 2001 04:53:57 -0000 Date: Tue, 7 Aug 2001 23:53:57 -0500 (CDT) From: Mike Silbersack To: Brian O'Shea Cc: Subject: Re: Tuning the 4.1-R kernel for networking In-Reply-To: <20010807213320.D529@ricochet.net> Message-ID: <20010807234907.S86161-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 7 Aug 2001, Brian O'Shea wrote: > Hello, > > I am using a PIII 550MHz UP system running FreeBSD 4.1-RELEASE. It has > a 3c905B-TX Fast Etherlink XL card. We're all working on getting 4.4 out the door right now, and unlikely to spend time working on 4.1 at this point in time. Please upgrade to -stable and see if the condition you describe still exists. If it does still exist, we can start to look into your problem. That being said, it looks like something is up; mbufs allocated to socket names and addresses don't appear as a result of most TCP connections. What type of sockets are you using? 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 7 21:55: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 8C33037B40A for ; Tue, 7 Aug 2001 21:55:57 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 8424181D07; Tue, 7 Aug 2001 23:55:47 -0500 (CDT) Date: Tue, 7 Aug 2001 23:55:47 -0500 From: Alfred Perlstein To: Brian O'Shea Cc: freebsd-hackers@freebsd.org Subject: Re: Tuning the 4.1-R kernel for networking Message-ID: <20010807235547.Z85642@elvis.mu.org> References: <20010807213320.D529@ricochet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010807213320.D529@ricochet.net>; from boshea@ricochet.net on Tue, Aug 07, 2001 at 09:33:20PM -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 * Brian O'Shea [010807 23:33] wrote: > Hello, > > I am using a PIII 550MHz UP system running FreeBSD 4.1-RELEASE. It has > a 3c905B-TX Fast Etherlink XL card. [snip] > I increased maxusers to 128 (2560 mbuf clusters) and it ran out of mbuf > clusters again. Then I increased it to 256 (4608 mbuf clusters), with > the same results. I don't have any sense of what is reasonable mbuf > cluster usage for the application that I am running, but the system > never seems to recover from the condition, which would seem to point to > an mbuf cluster leak. > > Does this sound like a problem with the driver (mbuf cluster leak), or > with the way that I have tuned this system? (the kernel config file for > this system is attached) > > I compiled a debug kernel and panicked the system while it was in the > state described above, in case that is any use. I don't know how to > analyze the crash dump to determine where the problem is. Any > suggestions are welcome. Your system isn't configured for high network throughput, you want to put something like: kern.ipc.nmbclusters=32768 this might also help: net.inet.tcp.tcbhashsize=32768 put those into /boot/loader.conf -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 7 23:30:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from poxy.bigpond.net.au (unknown [144.137.146.32]) by hub.freebsd.org (Postfix) with ESMTP id 14D0E37B417 for ; Tue, 7 Aug 2001 23:30:14 -0700 (PDT) (envelope-from md@drawcard.com) Received: from Director (director [192.168.0.10]) by poxy.bigpond.net.au (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA22918 for ; Wed, 8 Aug 2001 16:36:27 +1000 Message-Id: <200108080636.QAA22918@poxy.bigpond.net.au> From: "Damian Andrews" To: Date: Wed, 08 Aug 01 16:29:24 +1000 Subject: Deadline for .biz & .info approaches!! Reply-To: "Damian Andrews" X-Mailer: EMailing List Pro 3.7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00XBHFJ.0GP3VW05" Sender: owner-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_00XBHFJ.0GP3VW05 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Registrant, The most anticipated event since the first release of the dotcoms is here! If you haven't already done so it's time to pre-register your .biz and .info 'Top Level Domain Names' and stake your claim in what is fast becoming a LAND RUSH, "larger than the .com phenomena". With the deadline to pre-register your .biz Sept 17, 2001 and Sept 12, 2001 for .info domains approaching (your only real opportunity to secure a great .biz and/or .info) you must act now secure your trading or generic name(s). At the close of these periods all pre-registrations will be processed first. Up for grabs are names like; news.biz, show.biz and adult.info because of the 'Round Robin' [Not First Come First Serve] selection method adopted by ICANN, the release has effectively become "The Worlds Largest Lottery". We offer you [but only until September 18th 2001] to pre-register your selection of great names with three of the largest biz & .info registrars [Our Channel Partners] in a 3-5 minute process for one low price [as low as US$3.50 per name] this is the lowest price available anywhere including The Registrars Themselves. Heres how it works! Pre-register with one, two or all three of our channel partners at the same time and increase your chances of securing names like 'show.biz or easy.info' up to 300%. Pre-register as many names as you like and save up to 50% with volume discounts. Free.biz! Want to pre-register names like adult.biz for FREE. Easy.biz, simply go to www.drawcard.com enter in your email address at our affiliate page and I will send you an email, with your unique ID that can be forward to all in your address book then all who enter the site by way of that link will earn you US$1.00 per pre-registration. We have people registering 100+ names at a time. Now that's a good.biz! Any and all names you decide to register can come directly off your earnings or if you prefer I will send you a cheque! More_Free.info · For every 20 names or more you pre-register we will give you free for one year a sub-domain name from the very best of our 'channels partners' like 'yourname@pro.biz', 'yourname@badboy.info'. · Free home page with every account. · Free email with every account. This is your very best opportunity to secure 'yourfuture.biz'. But you must Pre-Register and you must do it NOW. Want to see more: http://www.drawcard.com (If this link is not working please cut and paste the link into your browser) If you have received this mailing in error, or do not wish to receive any further mailings from us, simply click here put in your email address and add Remove to the subject line: http://www.drawcard.com/index.cfm?fuseaction=CompanyInfo Damian Andrews MD Drawcard.com ------=_NextPart_000_00XBHFJ.0GP3VW05-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 0:26:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id CD93437B401 for ; Wed, 8 Aug 2001 00:26:52 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.139.128.Dial1.SanJose1.Level3.net [209.245.139.128]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA14369; Wed, 8 Aug 2001 00:26:42 -0700 (PDT) Message-ID: <3B70E9DB.B16F409C@mindspring.com> Date: Wed, 08 Aug 2001 00:27:23 -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: void Cc: freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <20010807221509.A24999@firedrake.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG void wrote: > > Can you name one SMP OS implementation that uses an > > "interrupt threads" approach that doesn't hit a scaling > > wall at 4 (or fewer) CPUs, due to heavier weight thread > > context switch overhead? > > Solaris, if I remember my Vahalia book correctly (isn't that a favorite > of yours?). As usual, IMO... Yes, I like the Vahalia book; I did technical review of it for Prentice Hall before its publication. Solaris hits the wall a little later, but it still hits the wall. On Intel hardware, it has historically hit it at the same 4 CPUs where everyone else tends to hit it, for the same reasons; as of Solaris 2.6, they have adopted the hybrid per CPU pool model recommended in Vahalia (Chapter 12). While I'm at it, I suppose I should recommend reading the definitive Solaris internals book, to date: Solaris Internals, Core Kernel Architecture Jim Mauro, Richard McDougall Prentice Hall ISBN: 0-13-022496-0 Solaris does use interrupt threads for some interrupts; I don't like the idea, for the reasons stated previously. Solaris claims to scale to 64 processors while maintaining SMP, rather than real or virtual NUMA. It's been my own experience that this scaling claim is not entirely accurate, if what you are doing is a lot of kernel processing. On the other hand, if you are running a lot of non-intersecting user space code (e.g. JVM's or CGI's), it's not as bad (and realized that FreeBSD is not that bad in the same situation, either: it's just not as common in practice as it is in theory). It should be noted that Solaris Interrupt threads are only used for interrupts of priority 10 and below: higher priority interrupts are _NOT_ handled by threads (interrupts at a priority level from 11 to 15). 10 is the clock interrupt. It should also be noted that Solaris maintains a per processor pool of interrupt threads for each of the lower priority interrupts, with a global thread that is used for handling of the clock interrupt. This is _very_ different than taking an interrupt thread, and rescheduling it on an arbitrary CPU, and as others have pointed out, the hardware used to do the scheduling is very different. In the 32 processor Sequent boxes, the actual system bus was different, and directly supported message passing. There is also specific hardware support for handling interrupts via threads, which is really not applicable to x86 or even the Alpha architectures on which FreeBSD currently runs, nor to the IA64 architecture (port in progress). In particular, there is a single system wide table, introduced with the UltraSPARC, that doesn't need to be locked to support interrupt handling. Also, the Sun system is still an IPL system, using level based blocking, rather than masking, and these threads can find themselves blocks on a mutex or condition variable for a relatively long time; if this happens, it resumes the previous thread _but does not drop its IPL below that of the suspended thread_, which is basically the Djikstra Banker's Algorithm method of avoiding priority inversion on interrupts (i.e. ugly). Finally, the Sun system "borrows" the context of the interrupted process (thread) for interrupt handling (the LWP). This is very similar to the technique employed with kernel vs. user space thread associations within the Windows kernels (this was one of the steps I was referring to when I said that NT had dealt with a number of scaling issues before it needed to, so that they would not turn into problems on 8-way and higher systems). Personally, I think that the Sun system is extremely succeptible to receiver livelock (Network interrupts are at 7, and disk interrupts are at 5, which means that so long as you are getting pounded with network interrupts for e.g. NFS read or write requests, you're not going to service the disk interrupts that will let you dispose of the traffic, nor will you run the user space code for things like CGI's or Apache servers trying to service a heavy load of requests for content). I'm also not terrifically impressed with their callout mechanism, when applied to networking, which has a preponderance of fixed, known interval timers, but FreeBSD's isn't really any better, which it comes to huge numbers of network connections, since it will end up hashing 2/4/6/8/... into the same bucket, unordered, which means traversing a large list of timers which are not going to end up expiring (callout wheels are not a good thing to mix with fixed interval timers of relatively long durations, like the 2MSL timers that live in the networking code, or most especially the TIME_WAIT timers). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 0:42:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 2982637B415 for ; Wed, 8 Aug 2001 00:42:30 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.139.128.Dial1.SanJose1.Level3.net [209.245.139.128]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA03047; Wed, 8 Aug 2001 00:42:26 -0700 (PDT) Message-ID: <3B70ED8B.2078F27A@mindspring.com> Date: Wed, 08 Aug 2001 00:43:07 -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: Julian Elischer Cc: hackers@FreeBSD.ORG Subject: Re: -Stable, apache, ldap and shlibs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Who is the expert on apache, modules and shlibs? > (I'll go offline to discuss the problem if I can find > an appropriate person.. (can't get ldap module to work with apache > under freebsd.) Build Apache from your own sources, and not from ports. You will also need to use the Netscape library to get LDAP support, unless things have changed very recently, and the OpenLDAP library has been supported without me knowing it. I have Apache + SLL + LDAP + IMAP + PHP4 + mod_auth + PAM_LDAP working on my laptop. I built from source, not from ports. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 0:56:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id D50F937B40C; Wed, 8 Aug 2001 00:56:36 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f787xcZ00644; Wed, 8 Aug 2001 00:59:39 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108080759.f787xcZ00644@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Semen A. Ustimenko" Cc: freebsd-hackers@FreeBSD.org Subject: Re: Kernel stack size In-reply-to: Your message of "Wed, 08 Aug 2001 00:17:13 +0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 00:59:38 -0700 From: Mike Smith Sender: owner-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 developing some code running in kernel that use a lot of stack. And it > seems i run into stack overflow. This results in some proc structure > related parts overwrite (particulary p->p_stats->p_timer[ITIMER_PROF]) and > unexpected signals. (Otherwise, it usually page faults inside > swi_net_next()) > > Could somebody explain how this can happen (i thought i would panic and > say ``stack oveflow'') and how this can be avoided? Use less stack. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 1:23:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ?????? (unknown [211.244.225.95]) by hub.freebsd.org (Postfix) with SMTP id CC62A37B401 for ; Wed, 8 Aug 2001 01:23:35 -0700 (PDT) (envelope-from ksj@edusarang.com) From: =?ks_c_5601-1987?B?w7XA57ChtcggssPC7g==?= To: hackers@FreeBSD.org Subject: =?ks_c_5601-1987?B?u+y4573DIL7Lt8G15bixsNS/5Cwguau9vMDPwMy15yCzsrq4tNkgvbGw1C4uLg==?= Date: Wed, 08 Aug 2001 17:23:12 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0177_01C0F08A.93A23C00" X-Priority: 3 Message-Id: <20010808082335.CC62A37B401@hub.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 This is a multi-part message in MIME format. ------=_NextPart_000_0177_01C0F08A.93A23C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 v6G14LvntvsguN7AzyC80r3EwfYgIAkJCQkJCQkJCQkJCQkJCQkNCgkJCQkgICAgICAgDQoN CiAgIA0Kx+O29L74wMwgIMDMuN7Az8C7ILq4s7sgwcu828fVtM+02S4gxbggu+fAzMauILDU vcPGx7+hvK0guavA28Cnt84gud/D6cfPv6kgurizu7nHt84gsLPAzsGkurggs+vD4sC6IMD8 x/QgsMbBpMfPwfYgvsrAuLzFtbUgwcG9wLTPtNkuICANCiAgICAgIAkJCQkJCQkJCQkJIA0K IA0KCQkJCSAgICAgDQoJCQkJIA0KIA0KCSAJCSAgICAgICAgICANCg0KICAgDQogsbPA5yAg x9Gxx8C7ILDtuK4tuea7573EICCx4r7vwLi3ziC/z7qux8+w1CAgseK+7yEhIQ0KICAgICAg ICAgICANCiANCiAgICAgICAgICAgDQoNCiAgIA0KIMPWvNIgIDS56MDHIMDQseIgvNO1tSAg udcgwMzH2LW1IMH1sKEhISENCiAgICAgICAgICAgDQogDQogICAgICAgICAgIA0KDQogICAN CiDD1rjpwLi3ziAgwOHA57XIIMfQvcC0ybf8ICCx+r/sseIhISENCiAgICAgICAgICAgDQog DQogICAgICAgICAgIA0KDQogICANCiAxutAgILq5vcDAuLfOIMD8w7wgs7u/6yAgxsS+xyEh IQ0KICAgICAgICAgICANCiANCiAgICAgICAgICAgDQoNCiAgIA0KILjuw7W03MCntvO1tSAg tei0wrTrt84gw7TDtCCw6LvqISEhDQogICAgICAgICAgIA0KIA0KICAgICAgICAgICANCg0K ICAgDQogNbrQv6EgIDEwMLTcvu64piC/z8D8ILHivu8hISENCiAgICAgICAgICAgDQogDQog ICAgICAgICAgICAgIA0KvPawrbTru/MNCg0Ktc6z+iAgsLO538DHIMPWtOsgwPu3ybHiwMcg w8q17sfQu/0gIC8gx9C9wLTJt/wgx+K788C7IL/4x8+0wiDH0Lv9ICC51yC89sfou/0gLyDA 2rHisLO53yC51yC+97mrtMm3/MC7ICDAp8fYILDtvcnHz7TCIMH3wOXAziAvIMDas+C/obDU ICDH0L3AILnmuf3AuyDA/MfYwdaw7cDaIMfPtMIgIMfQus648A0KICAgICAgICAgICANCiAg ICAgIA0KyKjG5MDMwfYgOiB3d3cuZWR1c2FyYW5nLmNvbSAgICAgICAgICAgICAgICAgbWFp bCA6IG1haWxAZWR1c2FyYW5nLmNvbQ0Kua7Ax8D8yK0gOiAoMDMxKSAgODIxLTEzMzQgICAg ICAgICAgICAgICAgICAgICAgICAgICC89r73ua7AxyAgLyDB9rvnua7AxyAvIMGmyN65rsDH DQogICAgICAgDQogDQogICANCiANCg== ------=_NextPart_000_0177_01C0F08A.93A23C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT6/obXgu+e2+yC43sDPILzSvcTB9jwvVElUTEU+DQo8 TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9InRleHQvaHRtbDsgY2hh cnNldD1ldWMta3IiPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJOYW1vIFdl YkVkaXRvciB2NC4wKFRyaWFsKSI+DQo8L0hFQUQ+DQo8Qk9EWSBCR0NPTE9SPSNGRkZGRkY+ DQo8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjEiIHdp ZHRoPSI1NDAiIGJnY29sb3I9ImJsYWNrIj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0 aD0iOTY0IiBiZ2NvbG9yPSJ3aGl0ZSI+PCEtLSBJbWFnZVJlYWR5IFNsaWNlcyAoVW50aXRs ZWQtMSkgLS0+DQo8VEFCTEUgQk9SREVSPTAgQ0VMTFBBRERJTkc9IjAiIENFTExTUEFDSU5H PTAgd2lkdGg9IjEwMCUiPg0KCTxUUj4NCgkJPFREPg0KCQkJPHAgYWxpZ249ImNlbnRlciI+ PGEgaHJlZj0iaHR0cDovL3d3dy5lZHVzYXJhbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+PGlt ZyBzcmM9Imh0dHA6Ly93d3cuZWR1c2FyYW5nLmNvbS9tYWlsL2ltYWdlcy90aXRsZS5naWYi IHdpZHRoPSI1NDQiIGhlaWdodD0iMTE2IiBib3JkZXI9IjAiPjwvYT4JCQk8L1REPg0KCTwv VFI+DQoJPFRSPg0KCQk8VEQgd2lkdGg9IjU0NCI+DQoJCQk8Zm9udCBzaXplPSIxIj48YnI+ PC9mb250PjwvVEQ+DQoJPC9UUj4NCgk8VFI+DQoJCTxURCB3aWR0aD0iNTQ0Ij4NCiAgICAg ICAgICAgICAgICAgICAgICAgIDx0YWJsZSBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMSIgd2lkdGg9IjUwMCIgYmdjb2xvcj0iIzAw MzQ3MSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjUzNCI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjAiIHdpZHRoPSIxMDAlIj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMjAiIGJnY29sb3I9IndoaXRlIj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwPjxpbWcgc3JjPSJo dHRwOi8vd3d3LmVkdXNhcmFuZy5jb20vbWFpbC9pbWFnZXMvc2lkZWJhcjEuZ2lmIiB3aWR0 aD0iMTAiIGhlaWdodD0iNTAiIGJvcmRlcj0iMCI+PC9wPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8dGQgYmdjb2xvcj0id2hpdGUiPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5cHQ7Ij48Zm9udCBjb2xvcj0iZ3JheSI+x+O29L74wMwgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDAzLjewM/AuyC6uLO7 IMHLvNvH1bTPtNkuIMW4ILvnwMzGriCw1L3Dxse/obytILmrwNvAp7fOILnfw+nHz7+pILq4 s7u5x7fOILCzwM7BpLq4ILPrw+LAuiDA/Mf0ILDGwaTHz8H2IL7KwLi8xbW1IMHBvcC0z7TZ LiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48 L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90cj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvdGFibGU+DQo8L1REPg0KCTwvVFI+ DQoJPFRSPg0KCQk8VEQgd2lkdGg9IjU0NCI+DQoJCQk8L1REPg0KCTwvVFI+DQoJPFRSPg0K CQk8VEQ+DQogICAgICAgICAgICAgICAgICAgICAgICA8cD48Zm9udCBzaXplPSIxIj4mbmJz cDs8L2ZvbnQ+PC9wPg0KPC9URD4NCgk8L1RSPg0KCTxUUj4NCgkJPFREPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPHAgYWxpZ249ImxlZnQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxpbWcgc3JjPSJodHRwOi8vd3d3LmVkdXNhcmFuZy5jb20vbWFpbC9pbWFnZXMvbGVjX3Rp dGxlMS5naWYiIHdpZHRoPSI4NiIgaGVpZ2h0PSIyMCIgYm9yZGVyPSIwIj48L3A+DQo8L1RE Pg0KCTwvVFI+DQoJPFRSPg0KCQk8VEQ+DQogICAgICAgICAgICAgICAgICAgICAgICA8cD48 Zm9udCBzaXplPSIxIj4mbmJzcDs8L2ZvbnQ+PC9wPg0KPC9URD4NCgk8L1RSPg0KICAgICAg ICAgICAgICAgIDx0cj4NCgkJPFREPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHRhYmxl IGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIiB3aWR0aD0iNTAwIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNTM0Ij4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMSIgd2lkdGg9IjEwMCUiIGJnY29sb3I9IiNGNjk4 MDQiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0cj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI0 OTAiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0 aD0iNDk4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTY3IiBiZ2NvbG9yPSJ3aGl0ZSI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8cD48aW1nIHNyYz0iaHR0cDovL3d3dy5lZHVzYXJhbmcuY29tL21haWwvaW1hZ2VzL2tp dWsuZ2lmIiB3aWR0aD0iMTUxIiBoZWlnaHQ9IjQxIiBib3JkZXI9IjAiIHVzZW1hcD0iI0lt YWdlTWFwMSI+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjMzMSIgYmdjb2xvcj0iI0ZB RUZERSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsiPjxmb250IGNv bG9yPSIjRjY5ODA0Ij48Yj4mbmJzcDuxs8DnIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgx9Gxx8C7ILDtuK4tuea7573E IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgseK+78C4t84gv8+6rsfPsNQgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCx4r7vISEhPC9iPjwvZm9udD48 L3NwYW4+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9 IjUzNCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD4mbmJzcDs8 L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNTM0Ij4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMSIgd2lkdGg9IjUwMCIgYmdjb2xvcj0i Izc1OTA0NyI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQ+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGFibGUg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI0OTgi Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDx0cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHRkIHdpZHRoPSIxNjgiIGJnY29sb3I9IndoaXRlIj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwPjxp bWcgc3JjPSJodHRwOi8vd3d3LmVkdXNhcmFuZy5jb20vbWFpbC9pbWFnZXMvc29rLmdpZiIg d2lkdGg9IjE1MSIgaGVpZ2h0PSI0MSIgYm9yZGVyPSIwIiB1c2VtYXA9IiNJbWFnZU1hcDIi PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSIzMzAiIGJnY29sb3I9IiNFNEYxQ0UiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPHA+PGZvbnQgY29sb3I9IiM3NTkwNDciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OXB0OyI+PGI+Jm5ic3A7w9a80iANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDS56MDHIMDQseIgvNO1tSANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgILnX IMDMx9i1tSDB9bChISEhPC9iPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RhYmxl Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjUzNCI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8cD4mbmJzcDs8L3A+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90cj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDx0ZCB3aWR0aD0iNTM0Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMSIgd2lkdGg9IjEwMCUiIGJnY29sb3I9IiMyMjZEM0EiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI0OTAiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNDk4Ij4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3 aWR0aD0iMTY4IiBiZ2NvbG9yPSJ3aGl0ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48aW1nIHNyYz0iaHR0cDov L3d3dy5lZHVzYXJhbmcuY29tL21haWwvaW1hZ2VzL2Nob2kuZ2lmIiB3aWR0aD0iMTUxIiBo ZWlnaHQ9IjQxIiBib3JkZXI9IjAiIHVzZW1hcD0iI0ltYWdlTWFwMyI+PC9wPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3Rk Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8dGQgd2lkdGg9IjMzMCIgYmdjb2xvcj0iI0UwRjNEOSI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48Yj48 Zm9udCBjb2xvcj0iIzIyNkQzQSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJz cDvD1rjpwLi3ziANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIMDhwOe1yCDH0L3AtMm3/CANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgILH6v+yx4iEhITwv c3Bhbj48L2ZvbnQ+PC9iPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PHRkIHdpZHRoPSI1MzQiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PHA+Jm5ic3A7PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lk dGg9IjUzNCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGFibGUg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjEiIHdpZHRoPSI1MDAi IGJnY29sb3I9IiMxMzZBQjUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHRkIHdpZHRoPSI0OTAiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIwIiB3aWR0aD0iNDk4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTY3IiBiZ2NvbG9y PSJ3aGl0ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8cD48aW1nIHNyYz0iaHR0cDovL3d3dy5lZHVzYXJhbmcuY29t L21haWwvaW1hZ2VzL21pbmQuZ2lmIiB3aWR0aD0iMTUxIiBoZWlnaHQ9IjQxIiBib3JkZXI9 IjAiIHVzZW1hcD0iI0ltYWdlTWFwNCI+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjMz MSIgYmdjb2xvcj0iI0REREVGOSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48Zm9udCBjb2xvcj0iIzEzNkFCNSI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4mbmJzcDsxutAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICC6ub3A wLi3ziDA/MO8ILO7v+sgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICDGxL7HISEhPC9zcGFuPjwvYj48L2ZvbnQ+PC9wPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RhYmxlPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjUzNCI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD4mbmJzcDs8L3A+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNTM0Ij4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMSIgd2lkdGg9IjEwMCUiIGJnY29sb3I9IiNCQjU5RDMiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI0OTAiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRhYmxl IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNDk4 Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDx0ZCB3aWR0aD0iMTY4IiBiZ2NvbG9yPSJ3aGl0ZSI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48 aW1nIHNyYz0iaHR0cDovL3d3dy5lZHVzYXJhbmcuY29tL21haWwvaW1hZ2VzL2N5YmVyLmdp ZiIgd2lkdGg9IjE1MSIgaGVpZ2h0PSI0MSIgYm9yZGVyPSIwIiB1c2VtYXA9IiNJbWFnZU1h cDUiPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSIzMzAiIGJnY29sb3I9IiNGMERERjYi Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHA+PGZvbnQgY29sb3I9IiNCQjU5RDMiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OXB0OyI+Jm5ic3A7uO7DtbTcwKe287W1IA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgtei0wrTrt84gw7TDtCCw 6LvqISEhPC9zcGFuPjwvYj48L2ZvbnQ+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8dGQgd2lkdGg9IjUzNCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8cD4mbmJzcDs8L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDx0ZCB3aWR0aD0iNTM0Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMSIgd2lk dGg9IjEwMCUiIGJnY29sb3I9IiNEMjNDMkIiPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHRkIHdpZHRoPSI0OTAiPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNDk4Ij4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTY4 IiBiZ2NvbG9yPSJ3aGl0ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48aW1nIHNyYz0iaHR0cDovL3d3dy5lZHVz YXJhbmcuY29tL21haWwvaW1hZ2VzL2VuZy5naWYiIHdpZHRoPSIxNTEiIGhlaWdodD0iNDEi IGJvcmRlcj0iMCIgdXNlbWFwPSIjSW1hZ2VNYXA2Ij48L3A+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3 aWR0aD0iMzMwIiBiZ2NvbG9yPSIjRjdFNkNGIj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwPjxmb250IGNvbG9yPSIj RDIzQzJCIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsiPiZuYnNwOzW60L+hIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMTAwtNy+7rimIL/PwPwgseK+7yEhITwvc3Bhbj48L2I+PC9mb250PjwvcD4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L3RyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC90YWJsZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L3RyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90YWJsZT4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0cj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI1MzQiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHA+Jm5ic3A7PC9wPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3RhYmxlPg0KPC9URD4NCiAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAg ICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAg ICAgICAgPHRhYmxlIGFsaWduPSJjZW50ZXIiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIxIiB3aWR0aD0iNTAwIiBiZ2NvbG9yPSJncmF5Ij4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDx0ZCB3aWR0aD0iNTM0Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDx0YWJsZSBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSI1IiBj ZWxsc3BhY2luZz0iMCIgd2lkdGg9IjUwMCI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8dGQgYmdjb2xvcj0id2hpdGUiPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Imdy YXkiPjxiPrz2sK2067vzPC9iPjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsi Pjxmb250IGNvbG9yPSJncmF5Ij48YnI+PGJyPrXOs/ogDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICCws7nfwMcgw9a06yDA+7fJseLAxyDDyrXu x9C7/SANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC8gx9C9wLTJt/wgx+K788C7IL/4x8+0wiDH0Lv9IA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgudcgvPbH6Lv9IC8gwNqx4rCzud8gudcgvve5 q7TJt/zAuyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIMCnx9ggsO29ycfPtMIgwffA5cDOIC8gwNqz4L+hsNQgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDH0L3AILnmuf3AuyDA/MfYwdaw7cDa IMfPtMIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICDH0LrOuPA8L2ZvbnQ+PC9zcGFuPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90YWJsZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICAgICAgICAgICAg PC90YWJsZT4NCjwvVEQ+DQogICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAg ICA8dHI+DQogICAgICAgICAgICAgICAgICAgIDx0ZD4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGFsaWduPSJjZW50ZXIiPiZuYnNwOzwvcD4NCjwvVEQ+DQogICAgICAgICAgICAg ICAgPC90cj4NCiAgICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgIDx0 ZCBoZWlnaHQ9IjE4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIDx0YWJsZSBhbGlnbj0i Y2VudGVyIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSI4IiBjZWxsc3BhY2luZz0iMSIgd2lk dGg9IjUwMCIgYmdjb2xvcj0iZ3JheSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg PHRyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjUzNCIg Ymdjb2xvcj0iI0Y3RjZGNiI+ICAgICAgICAgICAgICAgICAgICAgICAgPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5cHQ7Ij48Zm9udCBjb2xvcj0iZ3JheSI+yKjG5MDMwfYgOjwvZm9u dD4gPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZWR1c2FyYW5nLmNvbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5cHQ7Ij53d3cuZWR1c2FyYW5nLmNvbTwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBjb2xv cj0iZ3JheSI+bWFpbCA6PC9mb250PiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1haWxAZWR1 c2FyYW5nLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Ij5tYWlsQGVkdXNhcmFu Zy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0OyI+PGJyPjxmb250 IGNvbG9yPSJncmF5Ij65rsDHwPzIrSA6IDwvZm9udD48Zm9udCBjb2xvcj0icmVkIj4oMDMx KSANCiAgICAgICAgICAgICAgICAgICAgICAgIDgyMS0xMzM0ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86 bWFpbEBlZHVzYXJhbmcuY29tIj48Zm9udCBjb2xvcj0icmVkIj689r73ua7AxyANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gwfa757muwMcgLyDBpsjeua7Axzwv Zm9udD48L2E+PC9zcGFuPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgPC90YWJsZT4NCjwvVEQ+DQogICAgICAgICAgICAgICAgPC90cj4NCiAg ICAgICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgIDx0ZCBoZWlnaHQ9IjE4 Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxwPjxmb250IHNpemU9IjEiPiZuYnNwOzwv Zm9udD48L3A+DQo8L1REPg0KICAgICAgICAgICAgICAgIDwvdHI+DQo8L1RBQkxFPg0KICAg ICAgICA8L3RkPg0KICAgIDwvdHI+DQo8L3RhYmxlPg0KPHA+Jm5ic3A7PC9wPg0KPG1hcCBu YW1lPSJJbWFnZU1hcDEiPg0KPGFyZWEgc2hhcGU9InJlY3QiIGNvb3Jkcz0iNDMsIDIyLCA5 OCwgNDAiIGhyZWY9Imh0dHA6Ly93d3cuZWR1c2FyYW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pg0KPGFyZWEgc2hhcGU9InJlY3QiIGNvb3Jkcz0iOTksIDIwLCAxNDksIDQwIiBocmVmPSJo dHRwOi8vd3d3LmVkdXNhcmFuZy5jb20vc3JjL2hlYWQvbGVjX2ludHJvX2tpLmh0bSIgdGFy Z2V0PSJfYmxhbmsiPg0KPC9tYXA+PG1hcCBuYW1lPSJJbWFnZU1hcDIiPg0KPGFyZWEgc2hh cGU9InJlY3QiIGNvb3Jkcz0iNDMsIDIzLCA5NywgNDAiIGhyZWY9Imh0dHA6Ly93d3cuZWR1 c2FyYW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KPGFyZWEgc2hhcGU9InJlY3QiIGNvb3Jk cz0iOTksIDI0LCAxNDksIDM5IiBocmVmPSJodHRwOi8vd3d3LmVkdXNhcmFuZy5jb20vc3Jj L2hlYWQvbGVjX2ludHJvX3Nvay5odG0iIHRhcmdldD0iX2JsYW5rIj4NCjwvbWFwPjxtYXAg bmFtZT0iSW1hZ2VNYXAzIj4NCjxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9IjQ0LCAyMSwg OTgsIDQwIiBocmVmPSJodHRwOi8vd3d3LmVkdXNhcmFuZy5jb20iIHRhcmdldD0iX2JsYW5r Ij4NCjxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9IjEwMiwgMjAsIDE1MCwgNDAiIGhyZWY9 Imh0dHA6Ly93d3cuZWR1c2FyYW5nLmNvbS9zcmMvaGVhZC9sZWNfaW50cm9fY2hvaS5odG0i IHRhcmdldD0iX2JsYW5rIj4NCjwvbWFwPjxtYXAgbmFtZT0iSW1hZ2VNYXA0Ij4NCjxhcmVh IHNoYXBlPSJyZWN0IiBjb29yZHM9IjQ0LCAyMiwgOTgsIDQwIiBocmVmPSJodHRwOi8vd3d3 LmVkdXNhcmFuZy5jb20iIHRhcmdldD0iX2JsYW5rIj4NCjxhcmVhIHNoYXBlPSJyZWN0IiBj b29yZHM9IjEwMCwgMjIsIDE0NiwgMzkiIGhyZWY9Imh0dHA6Ly93d3cuZWR1c2FyYW5nLmNv bS9zcmMvaGVhZC9sZWNfaW50cm9fbWluZC5odG0iIHRhcmdldD0iX2JsYW5rIj4NCjwvbWFw PjxtYXAgbmFtZT0iSW1hZ2VNYXA1Ij4NCjxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9IjQz LCAyMywgOTYsIDQwIiBocmVmPSJodHRwOi8vd3d3LmVkdXNhcmFuZy5jb20iIHRhcmdldD0i X2JsYW5rIj4NCjxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9Ijk5LCAyMCwgMTUwLCAzOSIg aHJlZj0iaHR0cDovL3d3dy5lZHVzYXJhbmcuY29tL3NyYy9oZWFkL2xlY19pbnRyb19jeWJl ci5odG0iPg0KPC9tYXA+PG1hcCBuYW1lPSJJbWFnZU1hcDYiPg0KPGFyZWEgc2hhcGU9InJl Y3QiIGNvb3Jkcz0iNDMsIDIxLCA5NiwgNDAiIGhyZWY9Imh0dHA6Ly93d3cuZWR1c2FyYW5n LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KPGFyZWEgc2hhcGU9InJlY3QiIGNvb3Jkcz0iOTks IDIwLCAxNTAsIDM4IiBocmVmPSJodHRwOi8vd3d3LmVkdXNhcmFuZy5jb20vc3JjL2hlYWQv bGVjX2ludHJvX2VuZy5odG0iPg0KPC9tYXA+PCEtLSBFbmQgSW1hZ2VSZWFkeSBTbGljZXMg LS0+DQo8L0JPRFk+DQo8L0hUTUw+ ------=_NextPart_000_0177_01C0F08A.93A23C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 1:38:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 7AADF37B403 for ; Wed, 8 Aug 2001 01:38:51 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 9849 invoked by uid 1000); 8 Aug 2001 08:37:32 -0000 Date: Wed, 8 Aug 2001 11:37:32 +0300 From: Peter Pentchev To: Brian O'Shea Cc: freebsd-hackers@freebsd.org Subject: Re: Tuning the 4.1-R kernel for networking Message-ID: <20010808113732.E534@ringworld.oblivion.bg> Mail-Followup-To: Brian O'Shea , freebsd-hackers@freebsd.org References: <20010807213320.D529@ricochet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010807213320.D529@ricochet.net>; from boshea@ricochet.net on Tue, Aug 07, 2001 at 09:33:20PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 07, 2001 at 09:33:20PM -0700, Brian O'Shea wrote: > Hello, > > I am using a PIII 550MHz UP system running FreeBSD 4.1-RELEASE. It has > a 3c905B-TX Fast Etherlink XL card. > > # ifconfig xl0 > xl0: flags=8843 mtu 1500 > inet 10.34.24.62 netmask 0xfffffc00 broadcast 10.34.27.255 > inet6 fe80::2c0:4fff:fe20:3926%xl0 prefixlen 64 scopeid 0x1 > ether 00:c0:4f:20:39:26 > media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX 100baseTX > 10baseT/UTP 10baseT/UTP 100baseTX Apart from Alfred's suggestions to up some sysctl values, I would suggest - specifically for 3c905* cards - to explicitly configure the interface media (add 'media 100baseTX' to your ifconfig line). You did not report any throughput problems, so this might not be a problem for you; still, it might be worth trying. G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 1:58:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id A2C2837B401 for ; Wed, 8 Aug 2001 01:58:19 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f7891KZ01287; Wed, 8 Aug 2001 02:01:21 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108080901.f7891KZ01287@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: tlambert2@mindspring.com Cc: freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time In-reply-to: Your message of "Tue, 07 Aug 2001 11:15:05 PDT." <3B703029.2BB6D25A@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 02:01:20 -0700 From: Mike Smith Sender: owner-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: > > :What "this", exactly? > > : > > :That "virtual wire" mode is actually a bad idea for some > > :applications -- specifically, high speed networking with > > :multiple gigabit ethernet cards? > > > > All the cpu's don't get the interrupt, only one does. > > I think that you will end up taking an IPI (Inter Processor > Interrupt) to shoot down the cache line during an invalidate > cycle, when moving an interrupt processing thread from one > CPU to another. Terry; all this "thinking" you're doing is *really*bad*. I appreciate that you believe you're trying to "educate" us somehow. But what you're really doing right now is filling our list archives with convincing-sounding crap. People that are curious about this issue are likely to turn up your postings, and get *really* confused. Please. Just stop, ok? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 2:25:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 1921937B442 for ; Wed, 8 Aug 2001 02:25:28 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f789SOZ01539; Wed, 8 Aug 2001 02:28:24 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108080928.f789SOZ01539@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Kazutaka YOKOTA Cc: freebsd-hackers@freebsd.org Subject: Re: dmesg behaviour In-reply-to: Your message of "Wed, 08 Aug 2001 11:47:08 +0900." <200108080247.LAA05281@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 02:28:24 -0700 From: Mike Smith Sender: owner-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 system-specific. Typically, systems only clear memory on cold-boot, but the behaviour is not standardised. > As far as I understand, this feature works only if the machine does not > clear its memory upon reboot. AT compatibles clear memory during the > BIOS POST, thus, we don't see console log from the previous boot > on the i386 platform. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 2:28:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 61B5E37B418 for ; Wed, 8 Aug 2001 02:28:38 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f789VXZ01574; Wed, 8 Aug 2001 02:31:37 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108080931.f789VXZ01574@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "craig" Cc: tlambert2@mindspring.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Why page enable in Kernel space? In-reply-to: Your message of "Wed, 08 Aug 2001 09:40:27 +0800." <002001c11fab$19acaca0$051a0a0a@fd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Wed, 08 Aug 2001 02:31:33 -0700 From: Mike Smith Sender: owner-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 is important for you to send plain-text messages to public lists. > In general a address in a process is just a linear address which=A0refe= r to > physical address indirectly=A0 by page directory.=A0 This is reasonable= in > user space. However is it necessary to do such thing in kernel? It is s= ure > to have penalty when converting a linear address to physical thing. Is = it > worth doing such thing in kernel. No. Turning paging on/off is expensive on x86, and you can't do it = easily in some important cases. > I think the performance is the most > important in kernel, other thing is second. I remember in linux linear > address is real physical address in kernel space(is it true?). Why free= bsd > does not do in the same way? Identity-mapping virtual:physical addresses is not the same as disabling paging. Linux, like all other sane x86 protected-mode operating systems leaves paging enabled. -- = =2E.. every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 2:35: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id D8B1B37B409; Wed, 8 Aug 2001 02:35:00 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.139.128.Dial1.SanJose1.Level3.net [209.245.139.128]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA01950; Wed, 8 Aug 2001 02:34:59 -0700 (PDT) Message-ID: <3B7107EB.1AA36EE0@mindspring.com> Date: Wed, 08 Aug 2001 02:35:39 -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: Mike Smith Cc: freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108080901.f7891KZ01287@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > Terry; all this "thinking" you're doing is *really*bad*. > > I appreciate that you believe you're trying to "educate" us somehow. But > what you're really doing right now is filling our list archives with > convincing-sounding crap. People that are curious about this issue are > likely to turn up your postings, and get *really* confused. > > Please. Just stop, ok? Mike, I know you are convinced you know everything, and that of all the people who have worked professionally on SMP systems before, FreeBSD has only one guy I'm aware of in a design position for the SMP project, and a lot of students who think they know what they are doing, even though they can't cite the literature, but please... Read the email threads all the way through before commenting on my postings; the IPI issue is real for TLB shootdown, as was pointed out by others; it was quite late, and it's very understandable, given that I have aphasic dyslexia, that I substituted the wrong word. Rather than correcting things, as others have done, you have insisted that no issue exists. Effectively calling me an idiot in a public forum doesn't help your credibility, and you're doing more damage by denying that there is any issue whatsoever to be concerned about, and being pedantic about precise word usage, instead of addressing the issues and correcting my unintentional spoonerisms out of concern for the archives. Also please read the white paper reference I gave you about receiver livelock: interrupt threads were, and are, a bad idea, particularly on stock Intel SMP hardware -- so Solaris using that approach doesn't justify it any more than antique versions of IRIX using that approach do. If you don't want to believe be, then believe Jeff Mogul, but don't pretend that simply because I chose the wrong word, that there is no issue to consider. Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 2:38:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from arb.arb.za.net (arb.arb.za.net [196.7.148.4]) by hub.freebsd.org (Postfix) with ESMTP id 2223537B403 for ; Wed, 8 Aug 2001 02:38:52 -0700 (PDT) (envelope-from mark@grondar.za) Received: (from uucp@localhost) by arb.arb.za.net (8.11.3/8.11.3) with UUCP id f789cIU07161; Wed, 8 Aug 2001 11:38:18 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.5/8.11.4) with ESMTP id f77IceZ55541; Tue, 7 Aug 2001 19:38:40 +0100 (BST) (envelope-from mark@grondar.za) Message-Id: <200108071838.f77IceZ55541@grimreaper.grondar.za> To: "Eugene L. Vorokov" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pam_wheel References: <200108061834.f76IYBO64264@bugz.infotecs.ru> In-Reply-To: <200108061834.f76IYBO64264@bugz.infotecs.ru> ; from "Eugene L. Vorokov" "Mon, 06 Aug 2001 18:34:11 -0000." Date: Tue, 07 Aug 2001 19:38:39 +0100 From: Mark Murray Sender: owner-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 piece obviously has at least two errors. First, if PAM_OPT_AUTH_AS_SELF > is true, then value of user is undefined. It should probably log > pwd->pw_name instead. Second, check for root must of course be reversed > and become if (!pwd->pw_uid). Fixed locally. Commit coming soon. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 3: 7:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 8337E37B401 for ; Wed, 8 Aug 2001 03:07:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.139.128.Dial1.SanJose1.Level3.net [209.245.139.128]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA28851; Wed, 8 Aug 2001 03:07:08 -0700 (PDT) Message-ID: <3B710F75.FF20B38@mindspring.com> Date: Wed, 08 Aug 2001 03:07:49 -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: boshea@ricochet.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Tuning the 4.1-R kernel for networking References: <20010807213320.D529@ricochet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brian O'Shea wrote: > On this machine I run a program which simulates many (~150) simultaneous > TCP clients. This is actually a multithreaded Linux binary, and one > thread per simulated TCP client is created. After a few seconds the > system runs out of mbuf clusters: > > # netstat -m > 3231/3392/6144 mbufs in use (current/peak/max): > 1641 mbufs allocated to data This is 25 connections worth of full TCP window in a single direction. For 150 connections, you will need 150*16k*2/256, or 19,200 mbufs for a 16k window size, with both transmit and receive biffers full, or 9,600 mbufs, if you only have the receive windows full. > 182 mbufs allocated to packet headers This is really allocation for tcptempl structures for use in packet keepalive; it basically indicates that you have a total of 182 sockets open. > 1408 mbufs allocated to socket names and addresses Don't know why this is, but it means you need at least another 1408 mbufs... > 1536/1536/1536 mbuf clusters in use (current/peak/max) Your cluster count is way, way too small. The fact that you are maxing out at 1536 in all categories implies that you have filled your clusters out with full send or receive windows. An mbuf cluster is 2k, and is generally only filled with 1536 (MTU) bytes, unless it has been coelesced. Assuming that these are the result of full write windows, then you need _at least_ 2400 clusters (150x16k*2/2k) for bidirectional window fill. > 3920 Kbytes allocated to network (98% in use) Means you've only got 4M assigned to network resources, which is not a lot; I can see you using 5M for window buffers, alone, ignoring cluster headers and mbufs for sockets and the 1408 mbufs you disappeared into socket names and addresses. > 96993 requests for memory denied These are the number of MGET/MCLGET failures. > 0 requests for memory delayed None of them were malloc calls, they were all allocations of objects which can only be allocated from memory which you must reserve by compiling your kernel with the correct tuning parameters (or in some cases sysctls in loader.conf, but I can't tell you what works in 4.1, and what has to be done at config time; sorry). > 0 calls to protocol drain routines > > Also, I see a steady stream of these messages on the console: > > xl0: no memory for rx list -- packet dropped! > > >From the xl(4) man page: > > xl%d: no memory for rx list The driver failed to allocate an mbuf > for the receiver ring. Yeah; you are out of mbufs and cluster headers. We knew that. When the driver can't allocate a replacement mbuf, it drops the receive packet data, since it can't really safely leave an empty receive ring slot, since those are receive interrupt driven. Basically, you have exhausted all your receive resources. If I had to guess, I would say that your program was an HTTP load program of some kind, since you have a grundle of data packed up in your receive window, which is common when you receive data, but never bother actually reading it to make it go away. You could also change your program to set the window size down to a smaller size than the default (also a sysctl, to set it globally for all programs, as an administrative limit), and that would keep the sender from taking up as much memory, since you would advertise a smaller window to the sender. > Looking at the xl_newbuf() function in the xl driver, there are two > places where this message can be generated. It looks like the problem > is with the second case where the MCLGET fails, since we are running out > of those. It could still be either one, actually; your message that you quoted didn't match either one of the printf's... > I increased maxusers to 128 (2560 mbuf clusters) and it ran out of mbuf > clusters again. Then I increased it to 256 (4608 mbuf clusters), with > the same results. I don't have any sense of what is reasonable mbuf > cluster usage for the application that I am running, but the system > never seems to recover from the condition, which would seem to point to > an mbuf cluster leak. > > Does this sound like a problem with the driver (mbuf cluster leak), or > with the way that I have tuned this system? (the kernel config file for > this system is attached) Don't tune it this way: leave it at 16 or 32 users, and specifically increase the networking resources and MAXFILES (see /sys/i386/conf/LINT). Frankly, it sounds like your application is bad; does it limit itself to 150 connections, or is it trying to make as many connections as it possible can make? If so, then no matter how you tune the system, your program will always hit its head on a resource limit eventually. > I compiled a debug kernel and panicked the system while it was in the > state described above, in case that is any use. I don't know how to > analyze the crash dump to determine where the problem is. Any > suggestions are welcome. Did it panic from being in the state, or did you break to the debugger and force a crash? If it panic'ed, that's one thing: look at the traceback from the dump, and that should tell you where it blew up. You didn't _boot_ the kernel with the debugging symbols, right? That's a sure way to run yourself out of memory. You boot the kernel with the debugging information stripped (kernel, not kernel.debug, after doing a make following a config -g), and you only use the debug version for analyzing the system dump, or doing remote debugging (see the handbook). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 3:23:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 182EB37B40A for ; Wed, 8 Aug 2001 03:23:15 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.139.128.Dial1.SanJose1.Level3.net [209.245.139.128]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA26447; Wed, 8 Aug 2001 03:23:05 -0700 (PDT) Message-ID: <3B711332.2A6DBE1F@mindspring.com> Date: Wed, 08 Aug 2001 03:23:46 -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: craig Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why page enable in Kernel space? References: <002001c11fab$19acaca0$051a0a0a@fd.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 > craig wrote: > In general a address in a process is just a linear address which > refer to physical address indirectly by page directory. Or a virtual address that does not have a physical page behind it. Some kernel memory is swappable, and some is overcommitted, and the pages backing the page entries aren't committed until they are needed. > This is reasonable in user space. However is it necessary to do > such thing in kernel? Only if you want to be able to handle differential loads. 8-). > It is sure to have penalty when converting a linear address to > physical thing. Actually, the hardware does it for free, for the most part. > Is it worth doing such thing in kernel. Yes. Consider how you would write fault on copyout in order to cause the user space buffer you were copying kernel data to to be there to be written to otherwise. Also, realize that the KVA space stops where the user space ends, and that the virtual address spaces are effectively butted up against each other, with the user space being readable/writable from the kernel, but not vice versa. This would be very hard to do; in fact, you would end up doing a lot more work for paging, and you would have to ptov/vtop to convert between kernel and user space addresses, where right now, you only have to do that to give physical addresses to devices. Likewise, the virtual space doesn't care if the physical space is fragmented (and most drivers will do scatter/gather anyway), but real fragmentation might mean that you would be unable to allocate kernel memory larger than your largest fragment (you could do it, but you'd have to defrag physical memory, which could be hard). > I think the performance is the most important in kernel, other > thing is second. I remember in linux linear address is real > physical address in kernel space(is it true?). Why freebsd > does not do in the same way? It's not true; Linux does the same thing FreeBSD does. When a protected mode OS that uses VM starts up, it generally loads itself into memory, builds a virtual address space that looks exactly like the physical address space where it was loaded, but relocated, and then relocates itself and starts using the virtual memory system instead of the physical one. This is really a gross oversimplification, but you get the idea. If you want to get a better understanding of this, get the book: Protected Mode Software Architecture Tom Shanley MindShare, Inc. Addison-Wesley Publishing Co. ISBN: 020155447X It costs about US$30, new on Amazon. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 7:34:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id D4DB437B406 for ; Wed, 8 Aug 2001 07:34:15 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from vel@localhost) by bugz.infotecs.ru (8.11.5/8.11.4) id f78EY4o10303 for freebsd-hackers@freebsd.org; Wed, 8 Aug 2001 18:34:04 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108081434.f78EY4o10303@bugz.infotecs.ru> Subject: PFIL_HOOKS To: freebsd-hackers@freebsd.org Date: Wed, 8 Aug 2001 18:34:03 +0400 (MSD) 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 Hello, why isn't PFIL_HOOKS kernel compile option listed in NOTES ? If it just was forgotten, please add it. One trying to compile in ipfilter will get confused I think. Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 7:40:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iona.dcs.gla.ac.uk (iona.dcs.gla.ac.uk [130.209.240.35]) by hub.freebsd.org (Postfix) with ESMTP id 1054737B409 for ; Wed, 8 Aug 2001 07:40:05 -0700 (PDT) (envelope-from neugebar@dcs.gla.ac.uk) Received: from therese.dcs.gla.ac.uk ([130.209.241.134] helo=therese.dcs.gla.ac.uk.dcs.gla.ac.uk) by iona.dcs.gla.ac.uk with esmtp (Exim 3.13 #1) id 15UUV8-00053B-00; Wed, 08 Aug 2001 15:40:02 +0100 Received: by therese.dcs.gla.ac.uk.dcs.gla.ac.uk (8.11.3/Dumb) id f78EdtE30541; Wed, 8 Aug 2001 15:39:55 +0100 (BST) To: "Weiguang SHI" Cc: bright@mu.org, jeff@expertcity.com, freebsd-hackers@freebsd.org Subject: Re: timing question References: From: Rolf Neugebauer Date: 08 Aug 2001 15:39:54 +0100 In-Reply-To: "Weiguang SHI"'s message of "Tue, 07 Aug 2001 10:11:11 -0600" Message-ID: Lines: 46 User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Weiguang SHI" writes: > >From: Alfred Perlstein > >To: Jeff Behl > >CC: "'freebsd-hackers@freebsd.org'" > >Subject: Re: timing question > >Date: Mon, 6 Aug 2001 14:49:55 -0500 > > > >* Jeff Behl [010806 12:48] wrote: > > > please excuse and direct me to the right place if this isn't the > > appropriate > > > place to post this sort of question.... > > > > > > we're looking into moving to freebsd (yea!), but found the following > > > problem. It seems that the shortest amount of time the below code will > > > sleep for is 20 seconds! any call to nanosleep for 5,10, etc miliseconds > > > returns a 20 ms delay. are we doing something wrong? > > > >You may have to increase the kernel value for HZ so that you get > >more fine grained clock interrupts. > > I didn't look at the code but if increasing the value of 'hz' will > result in more clock-interrupts/sec thus more overhead, wouldn't it be > better to auto-adjust the clock-interrupt rate somewhere in the OS > to clock-interrupt at big strides in the beginning but at > finer-grained interval as the actual timeout event approaches? The overhead for increasing the hz value to say 1000 is not too severe. I used the simple benchmark from the Loadable Scheduler Modules for Linux project [1] to measure the scheduling overhead on a 4.3-stable box. Increasing hz from 100 to 1000 incurs an overhead of .4 % on a PIII 450MHz. NB. for achieving higher timer resolutions you might find it interesting to look at Soft-Timers at Rice [2]. Events are scheduled at the usual timer interrupt frequency but the time wheels are also checked at system-call and other interrupt times, thus, depending on load, achieving finer grained timer resolutions. The TOCS paper, referenced on that site, also describes a mixed approach between Soft-Timers and hardware timers to achieve tighter delay bounds. Rolf [1] http://resourcemanagement.unixsolutions.hp.com/WaRM/docs/loadable_sched.html#Performance Measurement [2] http://www.cs.rice.edu/CS/Systems/Soft-timers/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 7:48:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f122.pav2.hotmail.com [64.4.37.122]) by hub.freebsd.org (Postfix) with ESMTP id 3053E37B405; Wed, 8 Aug 2001 07:48:14 -0700 (PDT) (envelope-from weiguang_shi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Aug 2001 07:48:14 -0700 Received: from 129.128.238.223 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 08 Aug 2001 14:48:13 GMT X-Originating-IP: [129.128.238.223] From: "Weiguang SHI" To: grog@FreeBSD.org, tlambert2@mindspring.com Cc: bmilekic@technokratis.com, dillon@earth.backplane.com, zzhang@cs.binghamton.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Date: Wed, 08 Aug 2001 08:48:13 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2001 14:48:14.0187 (UTC) FILETIME=[26E493B0:01C12019] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I found an article on livelock at http://www.research.compaq.com/wrl/people/mogul/mogulpubsextern.html Just go there and search for "livelock". But I don't agree with Terry about the interrupt-thread-is-bad thing, because, if I read it correctly, the authors themself implemented their ideas in interrupt thread of the Digital Unix. Weiguang >From: Greg Lehey >To: Terry Lambert >CC: Bosko Milekic , Matt Dillon >, Zhihui Zhang , >freebsd-hackers@FreeBSD.ORG >Subject: Re: Allocate a page at interrupt time >Date: Wed, 8 Aug 2001 13:34:14 +0930 > >On Tuesday, 7 August 2001 at 1:58:21 -0700, Terry Lambert wrote: > > Bosko Milekic wrote: > >>> I keep wondering about the sagicity of running interrupts in > >>> threads... it still seems like an incredibly bad idea to me. > >>> > >>> I guess my major problem with this is that by running in > >>> threads, it's made it nearly impossibly to avoid receiver > >>> livelock situations, using any of the classical techniques > >>> (e.g. Mogul's work, etc.). > >> > >> References to published works? > > > > Just do an NCSTRL search on "receiver livelock"; you will get > > over 90 papers... > > > > http://ncstrl.mit.edu/ > > > > See also the list of participating institutions: > > > > http://ncstrl.mit.edu/Dienst/UI/2.0/ListPublishers > > > > It won't be that hard to find... Mogul has "only" published 92 > > papers. 8-) > >So much data, in fact, that you could hide anything behind it. Would >you like to be more specific? > > >>> It also has the unfortunate property of locking us into virtual > >>> wire mode, when in fact Microsoft demonstrated that wiring down > >>> interrupts to particular CPUs was good practice, in terms of > >>> assuring best performance. Specifically, running in virtual > >> > >> Can you point us at any concrete information that shows > >> this? Specifically, without being Microsoft biased (as is most > >> "data" published by Microsoft)? -- i.e. preferably third-party > >> performance testing that attributes wiring down of interrupts to > >> particular CPUs as _the_ performance advantage. > > > > FreeBSD was tested, along with Linux and NT, by Ziff Davis > > Labs, in Foster city, with the participation of Jordan > > Hubbard and Mike Smith. You can ask either of them for the > > results of the test; only the Linux and NT numbers were > > actually released. This was done to provide a non-biased > > baseline, in reaction to the Mindcraft benchmarks, where > > Linux showed so poorly. They ran quad ethernet cards, with > > quad CPUs; the NT drivers wired the cards down to seperate > > INT A/B/C/D interrupts, one per CPU. > >You carefully neglect to point out that this was the old SMP >implementation. I think this completely invalidates any point you may >have been trying to make. > > >>> wire mode means that all your CPUs get hit with the interrupt, > >>> whereas running with the interrupt bound to a particular CPU > >>> reduces the overall overhead. Even what we have today, with > >> > >> Obviously. > > > > I mention it because this is the direction FreeBSD appears > > to be moving in. Right now, Intel is shipping with seperate > > PCI busses; there is one motherboard from their serverworks > > division that has 16 seperate PCI busses -- which means that > > you can do simultaneous gigabit card DMA to and from memory, > > without running into bus contention, so long as the memory is > > logically seperate. NT can use this hardware to its full > > potential; FreeBSD as it exists, can not, and FreeBSD as it > > appears to be heading today (interrupt threads, etc.) seems > > to be in the same boat as Linux, et. al.. PCI-X will only > > make things worse (8.4 gigabit, burst rate). > >What do interrupt threads have to do with this? > >Terry, we've done a lot of thinking about performance implications >over the last 2 years, including addressing all of the points that you >appear to raise. A lot of it is in the archives. > >It's quite possible that we've missed something important that you >haven't. But if that's the case, we'd like you to state it. All I >see is you coming in, waving your hands and shouting generalities >which don't really help much. The fact that people are still >listening is very much an indication of the hope that you might come >up with something useful. But pointing to 92 papers and saying "it's >in there [somewhere]" isn't very helpful. > >Greg >-- >See complete headers for address and phone numbers > >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 8 7:54: 3 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 9F56837B406 for ; Wed, 8 Aug 2001 07:53:58 -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 HAA17988 for ; Wed, 8 Aug 2001 07:53:58 -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 Date: Wed, 08 Aug 2001 07:53:59 -0700 (PDT) From: John Baldwin To: hackers@FreeBSD.org Subject: [PATCH] Change lockmgr() to not recursively panic Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Any objections to the following patch? Index: kern_lock.c =================================================================== RCS file: /usr/cvs/src/sys/kern/kern_lock.c,v retrieving revision 1.46 diff -u -r1.46 kern_lock.c --- kern_lock.c 2001/04/28 12:11:01 1.46 +++ kern_lock.c 2001/08/07 22:06:30 @@ -242,6 +242,11 @@ mtx_unlock(interlkp); } + if (panicstr != NULL) { + mtx_unlock(lkp->lk_interlock); + return (0); + } + extflags = (flags | lkp->lk_flags) & LK_EXTFLG_MASK; switch (flags & LK_TYPE_MASK) { -- 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 Wed Aug 8 9:49:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by hub.freebsd.org (Postfix) with ESMTP id C3A0537B40D for ; Wed, 8 Aug 2001 09:49:51 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 86B3238BD5 for ; Wed, 8 Aug 2001 13:49:44 -0300 (EST) Received: (qmail 8722 invoked by uid 0); 8 Aug 2001 16:48:52 -0000 Received: from duckman.distro.conectiva (HELO duckman.conectiva.com.br) (root@10.0.17.2) by burns.conectiva with SMTP; 8 Aug 2001 16:48:52 -0000 Received: from localhost (riel@localhost) by duckman.conectiva.com.br (8.11.4/8.11.3) with ESMTP id f78Gnb828080; Wed, 8 Aug 2001 13:49:43 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Wed, 8 Aug 2001 13:49:37 -0300 (BRST) From: Rik van Riel X-X-Sender: To: craig Cc: , Subject: Re: Why page enable in Kernel space? In-Reply-To: <002001c11fab$19acaca0$051a0a0a@fd.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 Wed, 8 Aug 2001, craig wrote: > I think the performance is the most important in kernel, other > thing is second. I remember in linux linear address is real > physical address in kernel space(is it true?). Why freebsd does > not do in the same way? 1) wouldn't you think things like reliability to be more important than performance? ;) 2) Linux uses a 1:1 mapping of physical memory for the bulk of kernel memory, with physical address 0 mapped at virtual address 0xc0000000 and using 4MB pages 3) FreeBSD does do something remarkably similar, except that FreeBSD, IIRC, seems to put more of its data in 4 kB pages so the system has more flexibility wrt. where to allocate the kernel data ? regards, Rik -- IA64: a worthy successor to the i860. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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 8 10:20:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dopey.corp.expertcity.com (host1.expertcity.rangefire.net [216.64.159.146]) by hub.freebsd.org (Postfix) with ESMTP id 3CDB737B406 for ; Wed, 8 Aug 2001 10:20:29 -0700 (PDT) (envelope-from jeff@expertcity.com) Received: by dopey.corp.expertcity.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 10:21:21 -0700 Message-ID: <0307F3737A2AD511A42200D0B7A071919A4043@dopey.corp.expertcity.com> From: Jeff Behl To: "'freebsd-hackers@freebsd.org'" Subject: RE: timing question Date: Wed, 8 Aug 2001 10:21:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 thanks to all for the help with the timing question. Increasing the hz to 400 (in param.c) allowed for granularity of 5ms, which is what we needed. For those as unknowing as I was about unix timing, I ran across the following url which explained why a setting of 400hz allows for a max resolution of twice the tick amount (2.5ms).: http://www.ripe.net/ripencc/mem-services/ttm/Notes/PAM2001/node6.html#SECTIO N00061000000000000000 jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 11:20:12 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 12EF237B40D; Wed, 8 Aug 2001 11:20:05 -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 LAA76431; Wed, 8 Aug 2001 11:17:40 -0700 (PDT) Date: Wed, 8 Aug 2001 11:17:38 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: hackers@FreeBSD.org Subject: Re: [PATCH] Change lockmgr() to not recursively 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 not from me, though you might say why you want this.. On Wed, 8 Aug 2001, John Baldwin wrote: > Any objections to the following patch? > > Index: kern_lock.c > =================================================================== > RCS file: /usr/cvs/src/sys/kern/kern_lock.c,v > retrieving revision 1.46 > diff -u -r1.46 kern_lock.c > --- kern_lock.c 2001/04/28 12:11:01 1.46 > +++ kern_lock.c 2001/08/07 22:06:30 > @@ -242,6 +242,11 @@ > mtx_unlock(interlkp); > } > > + if (panicstr != NULL) { > + mtx_unlock(lkp->lk_interlock); > + return (0); > + } > + > extflags = (flags | lkp->lk_flags) & LK_EXTFLG_MASK; > > switch (flags & LK_TYPE_MASK) { > > > -- > > 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 Wed Aug 8 11:23:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (dsl081-058-209.dsl-isp.net [64.81.58.209]) by hub.freebsd.org (Postfix) with ESMTP id E0B8A37B421; Wed, 8 Aug 2001 11:23:02 -0700 (PDT) (envelope-from jasone@canonware.com) Received: by canonware.com (Postfix, from userid 1001) id 843F9DD; Wed, 8 Aug 2001 11:28:47 -0700 (PDT) Date: Wed, 8 Aug 2001 11:28:47 -0700 From: Jason Evans To: Julian Elischer Cc: John Baldwin , hackers@FreeBSD.org Subject: Re: [PATCH] Change lockmgr() to not recursively panic Message-ID: <20010808112847.F80920@canonware.com> 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 julian@elischer.org on Wed, Aug 08, 2001 at 11:17:38AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Aug 08, 2001 at 11:17:38AM -0700, Julian Elischer wrote: > not from me, though you might say why you want this.. I think the reason was in the Subject line: Subject: [PATCH] Change lockmgr() to not recursively panic Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 11:44:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 6AAAD37B40E for ; Wed, 8 Aug 2001 11:44:16 -0700 (PDT) (envelope-from boshea@netapp.com) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f78IiEX10876; Wed, 8 Aug 2001 11:44:14 -0700 (PDT) Received: from shaolin.hq.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f78IiEM28984; Wed, 8 Aug 2001 11:44:14 -0700 (PDT) Received: (from boshea@localhost) by shaolin.hq.netapp.com (8.9.3/8.9.3) id LAA13894; Wed, 8 Aug 2001 11:44:13 -0700 (PDT) (envelope-from boshea) Date: Wed, 8 Aug 2001 11:44:13 -0700 From: "Brian O'Shea" To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Tuning the 4.1-R kernel for networking Message-ID: <20010808114413.E529@ricochet.net> Reply-To: boshea@ricochet.net Mail-Followup-To: Brian O'Shea , Terry Lambert , freebsd-hackers@FreeBSD.ORG References: <20010807213320.D529@ricochet.net> <3B710F75.FF20B38@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <3B710F75.FF20B38@mindspring.com>; from tlambert2@mindspring.com on Wed, Aug 08, 2001 at 03:07:49AM -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 Wow, much useful feedback. Thanks. Terry, your general formula for nmbclusters per connection is pretty much what I am looking for. Great stuff. > Frankly, it sounds like your application is bad; does it limit > itself to 150 connections, or is it trying to make as many > connections as it possible can make? If so, then no matter > how you tune the system, your program will always hit its head > on a resource limit eventually. The application attempts to create a specified number of client connections (i.e. even in the absence of resource limits, it will only create 150 client connections, in this particular configuration). > > I compiled a debug kernel and panicked the system while it was in the > > state described above, in case that is any use. I don't know how to > > analyze the crash dump to determine where the problem is. Any > > suggestions are welcome. > > Did it panic from being in the state, or did you break to the > debugger and force a crash? I forced the crash to get a core file, in case it was useful in debugging. > You didn't _boot_ the kernel with the debugging symbols, right? Uhh, ... :) I booted the debug kernel (with debugging symbols) for one test so that I could get a crash dump. I have since booted only the stripped kernel. Thanks to everyone for your help. -brian p.s. Upgrading the machine is on the list of things to do. I'm a bit hesitant to keep up to date with -STABLE as I have had some bad experiences doing that. Possibly a monthly upgrade while closely monitoring the -stable mailing list for known problems would be feasible. -- Brian O'Shea To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 11:55:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 830D437B403 for ; Wed, 8 Aug 2001 11:55:19 -0700 (PDT) (envelope-from boshea@netapp.com) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f78ItHX11576; Wed, 8 Aug 2001 11:55:18 -0700 (PDT) Received: from shaolin.hq.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f78ItHl01008; Wed, 8 Aug 2001 11:55:17 -0700 (PDT) Received: (from boshea@localhost) by shaolin.hq.netapp.com (8.9.3/8.9.3) id LAA13932; Wed, 8 Aug 2001 11:55:16 -0700 (PDT) (envelope-from boshea) Date: Wed, 8 Aug 2001 11:55:16 -0700 From: "Brian O'Shea" To: Alfred Perlstein Cc: freebsd-hackers@freebsd.org Subject: Re: Tuning the 4.1-R kernel for networking Message-ID: <20010808115516.F529@ricochet.net> Reply-To: boshea@ricochet.net Mail-Followup-To: Brian O'Shea , Alfred Perlstein , freebsd-hackers@freebsd.org References: <20010807213320.D529@ricochet.net> <20010807235547.Z85642@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010807235547.Z85642@elvis.mu.org>; from bright@mu.org on Tue, Aug 07, 2001 at 11:55:47PM -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 07, 2001 at 11:55:47PM -0500, Alfred Perlstein wrote: [...] > Your system isn't configured for high network throughput, you > want to put something like: > > kern.ipc.nmbclusters=32768 > > this might also help: > net.inet.tcp.tcbhashsize=32768 > > put those into /boot/loader.conf So to clarify, if I just add these lines as-is to /boot/loader.conf, these sysctl variables will be set on the next boot? The current contents of loader.conf on this system is: # -- sysinstall generated deltas -- # userconfig_script_load="YES" Thanks, -brian -- Brian O'Shea To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 12: 0:13 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 1D3E637B622 for ; Wed, 8 Aug 2001 12:00:04 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 196DD81D05; Wed, 8 Aug 2001 13:59:54 -0500 (CDT) Date: Wed, 8 Aug 2001 13:59:54 -0500 From: Alfred Perlstein To: Brian O'Shea , freebsd-hackers@freebsd.org Subject: Re: Tuning the 4.1-R kernel for networking Message-ID: <20010808135954.F85642@elvis.mu.org> References: <20010807213320.D529@ricochet.net> <20010807235547.Z85642@elvis.mu.org> <20010808115516.F529@ricochet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010808115516.F529@ricochet.net>; from boshea@ricochet.net on Wed, Aug 08, 2001 at 11:55:16AM -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 * Brian O'Shea [010808 13:55] wrote: > On Tue, Aug 07, 2001 at 11:55:47PM -0500, Alfred Perlstein wrote: > [...] > > Your system isn't configured for high network throughput, you > > want to put something like: > > > > kern.ipc.nmbclusters=32768 > > > > this might also help: > > net.inet.tcp.tcbhashsize=32768 > > > > put those into /boot/loader.conf > > So to clarify, if I just add these lines as-is to /boot/loader.conf, > these sysctl variables will be set on the next boot? > > The current contents of loader.conf on this system is: > > # -- sysinstall generated deltas -- # > userconfig_script_load="YES" yessir. In fact in 4.4 you can futz with maxusers in the same way. -- -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 8 12:23:55 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 7E85437B40E for ; Wed, 8 Aug 2001 12:23:48 -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 MAA22783; Wed, 8 Aug 2001 12:23:12 -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: Date: Wed, 08 Aug 2001 11:50:02 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: Re: [PATCH] Change lockmgr() to not recursively panic 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 08-Aug-01 Julian Elischer wrote: > not from me, though you might say why you want this.. Ever had a panic. Tried to get a dump, and then had lockmgr blow up with some other panic? That's what this is trying to prevent. I'll have to make sure that case is still reproducible, however. Haven't seen it in a while. -- 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 Wed Aug 8 13: 0:25 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 492C437B42C; Wed, 8 Aug 2001 13:00:08 -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 MAA76835; Wed, 8 Aug 2001 12:59:25 -0700 (PDT) Date: Wed, 8 Aug 2001 12:59:24 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: hackers@FreeBSD.org Subject: Re: [PATCH] Change lockmgr() to not recursively 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 ah yes stupid of me.. yes..... On Wed, 8 Aug 2001, John Baldwin wrote: > > On 08-Aug-01 Julian Elischer wrote: > > not from me, though you might say why you want this.. > > Ever had a panic. Tried to get a dump, and then had lockmgr blow up with > some other panic? That's what this is trying to prevent. I'll have to make > sure that case is still reproducible, however. Haven't seen it in a while. > > -- > > 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 Wed Aug 8 13:50: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by hub.freebsd.org (Postfix) with ESMTP id 438BF37B412 for ; Wed, 8 Aug 2001 13:50:01 -0700 (PDT) (envelope-from janb@cs.utep.edu) Received: from gecko (gecko [129.108.5.51]) by cs.utep.edu (8.11.3/8.11.3) with ESMTP id f78Knne22294 for ; Wed, 8 Aug 2001 14:49:49 -0600 (MDT) Date: Wed, 8 Aug 2001 14:49:49 -0600 (MDT) From: X-Sender: To: Subject: Newbus 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 I would very much like to know, exaclty which files comprise the code for NEWBUS, excluding the drivers themselves.Can anyone help Thanks a lot, JAn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 14:34: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from devserver (unknown [64.132.176.66]) by hub.freebsd.org (Postfix) with ESMTP id 3CA8A37B649 for ; Wed, 8 Aug 2001 14:33:39 -0700 (PDT) (envelope-from support@tipclub.com) Received: from mail pickup service by devserver with Microsoft SMTPSVC; Wed, 8 Aug 2001 17:33:05 -0400 From: To: Subject: Welcome To Tipclub Date: Wed, 8 Aug 2001 17:33:05 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 08 Aug 2001 21:33:05.0683 (UTC) FILETIME=[B5C0B630:01C12051] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You have been referred to us to receive a Free Trial Membership to the first-ever online Tip Club. Tip Club is a local, online sales referral network whereas you share sales opportunities with members in your community - online!!!. Some people call them "breakfast clubs", "lead networks", or "referral clubs". We are the first to do it on the Internet! Membership is exclusive, once you sign up no other companies in your industry can join in your area. For more information, check us out at http://www.TipClub.com. If your interested, please reserve your industry opening now. Email us back with "Yes" on the subject line. Please include in your response your name, company name, industry and phone number. We only ask that if you join, you agree to be an active participant. If your not interested, just reply "No" in the subject line and and we will remove you from our referral list. Thank you! Sincerely, Tip Club Manager P.S. Refer five people to Tip Club and, if they join, receive a years membership free! Learn more about how tip clubs work: http://www.bni-sac.com/sacbee17jul.html http://centralohio.thesource.net/Files/9508162.html http://www.entrepreneur.com/Magazines/MA_SegArticle/0,1539,266943----1-,00 html http://austin.bcentral.com/austin/stories/1997/05/12/smallb4.html http://www.augustachronicle.com/stories/120699/abc_biztips.shtml http://columbus.bcentral.com/columbus/stories/1998/09/21/smallb1.html http://atlanta.bcentral.com/atlanta/stories/1999/07/19/smallb1.html http://columbus.bcentral.com/columbus/stories/2000/10/09/smallb1.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 15:20:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from postfix.sekt7.org (209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com [209.6.248.16]) by hub.freebsd.org (Postfix) with ESMTP id 6446237B41A for ; Wed, 8 Aug 2001 15:20:23 -0700 (PDT) (envelope-from ems@open-root.org) Received: from smtp.sekt7.org (postfix.sekt7.org [169.69.6.38]) by postfix.sekt7.org (Postfix) with SMTP id 92C923A07E for ; Wed, 8 Aug 2001 18:20:19 -0400 (EDT) From: Evan Sarmiento To: freebsd-hackers@freebsd.org Subject: mutex locking pgrp Message-Id: <20010808222019.92C923A07E@postfix.sekt7.org> Date: Wed, 8 Aug 2001 18:20:19 -0400 (EDT) Sender: owner-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 was looking through kern_proc.c, and I noticed that unlike pfind, pgfind does not lock the pointer to a structure being returned, further investigating showed that the definition fo the pgrp structure itself, in proc.h, doesn't have a mtx struct defined within it either. My proposal is to create a patch that would create pgrp locking, by adding a mtx to pgrp, and then a MACRO which locks and unlocks that structure, like PROC_LOCK() Would this create any problems? Also, my pr has been sitting in gnats for a while, I think that patch may be beneficial... http://www.freebsd.org/cgi/query-pr.cgi?pr=29423 -- ----------------------------------- Evan Sarmiento | www.open-root.org ems@sekt7.org | www.sekt7.org/~ems/ ----------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 15:24:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id 3A4A137B406; Wed, 8 Aug 2001 15:24:34 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NHPRWSXR; Thu, 9 Aug 2001 02:00:04 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f78M8W148715; Thu, 9 Aug 2001 02:08:32 +0400 (MSD) (envelope-from yar) Date: Thu, 9 Aug 2001 02:08:31 +0400 From: Yar Tikhiy To: hackers@freebsd.org, security@freebsd.org Subject: finger/fingerd & home directory permissions Message-ID: <20010809020831.B44660@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Hello, [Once I've sent this to -audit, but then was pointed] [that it wasn't the right list for such a discussion] Currently, finger(1) reveals user information if the user has created the ``.nofinger'' file, but his home directory is unreadable for finger(1). In the case of local access, it's no problem, since anyone may read /etc/passwd directly. OTOH, letting remote folks peek at user information even if the user wants to hide himself is a bad thing. The issue I'd like to submit to discussion is what way to choose: a) Add a command-line option to finger(1) and fingerd(8) telling them not to reveal user information if the user's homedir is protected. b) Similar to a), but hide such users by default. c) Don't bother at all :-) Personally, I'd prefer b) since it's most secure and seems to break nothing. Do I overlook any complications? -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 15:35:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (Postfix) with ESMTP id 64F6537B401; Wed, 8 Aug 2001 15:35:04 -0700 (PDT) (envelope-from danderse@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by wrath.cs.utah.edu (8.11.1/8.11.1) with ESMTP id f78MZ3L10346; Wed, 8 Aug 2001 16:35:03 -0600 (MDT) From: David G Andersen Received: (from danderse@localhost) by faith.cs.utah.edu (8.11.1/8.11.1) id f78MZ2p10632; Wed, 8 Aug 2001 16:35:02 -0600 (MDT) Message-Id: <200108082235.f78MZ2p10632@faith.cs.utah.edu> Subject: Re: finger/fingerd & home directory permissions To: yar@FreeBSD.ORG (Yar Tikhiy) Date: Wed, 8 Aug 2001 16:35:02 -0600 (MDT) Cc: hackers@FreeBSD.ORG, security@FreeBSD.ORG In-Reply-To: <20010809020831.B44660@comp.chem.msu.su> from "Yar Tikhiy" at Aug 09, 2001 02:08:31 AM 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 Lo and behold, Yar Tikhiy once said: > > In the case of local access, it's no problem, since anyone may read > /etc/passwd directly. OTOH, letting remote folks peek at user > information even if the user wants to hide himself is a bad thing. > > The issue I'd like to submit to discussion is what way to choose: > > a) Add a command-line option to finger(1) and fingerd(8) telling > them not to reveal user information if the user's homedir is > protected. > > b) Similar to a), but hide such users by default. > > c) Don't bother at all :-) > > Personally, I'd prefer b) since it's most secure and seems to break > nothing. Do I overlook any complications? Yes - it breaks the semantics of the existing fingerds that people are used to. It's a gratuitious change with little benefit that would simply confuse people who have a reasonable expectation about what the default behavior of 'finger' should be. Don't do (b). -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 19:27:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id C8E0137B403 for ; Wed, 8 Aug 2001 19:27:26 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id ED0DF6ACE1; Thu, 9 Aug 2001 11:57:42 +0930 (CST) Date: Thu, 9 Aug 2001 11:57:42 +0930 From: Greg Lehey To: Terry Lambert Cc: void , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time Message-ID: <20010809115742.E73579@wantadilla.lemis.com> References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <20010807221509.A24999@firedrake.org> <3B70E9DB.B16F409C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B70E9DB.B16F409C@mindspring.com>; from tlambert2@mindspring.com on Wed, Aug 08, 2001 at 12:27:23AM -0700 Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-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 Wednesday, 8 August 2001 at 0:27:23 -0700, Terry Lambert wrote: > void wrote: >>> Can you name one SMP OS implementation that uses an >>> "interrupt threads" approach that doesn't hit a scaling >>> wall at 4 (or fewer) CPUs, due to heavier weight thread >>> context switch overhead? >> >> Solaris, if I remember my Vahalia book correctly (isn't that a favorite >> of yours?). > > As usual, IMO... > > Yes, I like the Vahalia book; I did technical review of > it for Prentice Hall before its publication. > > Solaris hits the wall a little later, but it still hits the > wall. Every SMP system experiences performance degradation at some point. The question is a matter of the extent. > On Intel hardware, it has historically hit it at the same 4 CPUs > where everyone else tends to hit it, for the same reasons; This is a very broad statement. You contradict it further down. > as of Solaris 2.6, they have adopted the hybrid per CPU pool model > recommended in Vahalia (Chapter 12). > > While I'm at it, I suppose I should recommend reading the > definitive Solaris internals book, to date: > > Solaris Internals, Core Kernel Architecture > Jim Mauro, Richard McDougall > Prentice Hall > ISBN: 0-13-022496-0 Yes, I have this book. It looks very good, but I haven't found time to read it. > Solaris claims to scale to 64 processors while maintaining SMP, > rather than real or virtual NUMA. It's been my own experience that > this scaling claim is not entirely accurate, if what you are doing > is a lot of kernel processing. I think that depends on how you interpret the claim. It can only mean that adding a 64th processor can still be of benefit. > On the other hand, if you are running a lot of non-intersecting user > space code (e.g. JVM's or CGI's), it's not as bad (and realized that > FreeBSD is not that bad in the same situation, either: it's just not > as common in practice as it is in theory). You're just describing a fact of life about UNIX SMP support. > It should be noted that Solaris Interrupt threads are only > used for interrupts of priority 10 and below: higher priority > interrupts are _NOT_ handled by threads (interrupts at a > priority level from 11 to 15). 10 is the clock interrupt. FreeBSD also has provision for not using interrupt threads for everything. It's clearly too early to decide which interrupts should be left as traditional interrupts, and we've done some shifting back and forth to get things to work. Note that the priority numbers are noise. In this statement, they're just a convenient way to distinguish between threaded and non-threaded interrupts. > It should also be noted that Solaris maintains a per processor pool > of interrupt threads for each of the lower priority interrupts, with > a global thread that is used for handling of the clock interrupt. > This is _very_ different than taking an interrupt thread, and > rescheduling it on an arbitrary CPU, and as others have pointed out, > the hardware used to do the scheduling is very different. I think somebody else has pointed out that we're very conscious of CPU affinity. > In the 32 processor Sequent boxes, the actual system bus was > different, and directly supported message passing. Was this better or worse? > There is also specific hardware support for handling interrupts > via threads, which is really not applicable to x86 or even the > Alpha architectures on which FreeBSD currently runs, nor to the > IA64 architecture (port in progress). In particular, there is > a single system wide table, introduced with the UltraSPARC, that > doesn't need to be locked to support interrupt handling. > > Also, the Sun system is still an IPL system, using level based > blocking, rather than masking, and these threads can find > themselves blocks on a mutex or condition variable for a > relatively long time; if this happens, it resumes the previous > thread _but does not drop its IPL below that of the suspended > thread_, which is basically the Djikstra Banker's Algorithm > method of avoiding priority inversion on interrupts (i.e. ugly). So you're saying we're doing it better? > Finally, the Sun system "borrows" the context of the interrupted > process (thread) for interrupt handling (the LWP). This is very > similar to the technique employed with kernel vs. user space thread > associations within the Windows kernels (this was one of the steps I > was referring to when I said that NT had dealt with a number of > scaling issues before it needed to, so that they would not turn into > problems on 8-way and higher systems). This is also the method we're planning to use, as I'm sure you're aware from previous messages on the -smp list. > Personally, I think that the Sun system is extremely succeptible to > receiver livelock (Network interrupts are at 7, and disk interrupts > are at 5, which means that so long as you are getting pounded with > network interrupts for e.g. NFS read or write requests, you're not > going to service the disk interrupts that will let you dispose of > the traffic, nor will you run the user space code for things like > CGI's or Apache servers trying to service a heavy load of requests > for content). Can you point to a system which does better, and explain why? > I'm also not terrifically impressed with their callout mechanism, > when applied to networking, which has a preponderance of fixed, > known interval timers, but FreeBSD's isn't really any better, which > it comes to huge numbers of network connections, since it will end > up hashing 2/4/6/8/... into the same bucket, unordered, which means > traversing a large list of timers which are not going to end up > expiring (callout wheels are not a good thing to mix with fixed > interval timers of relatively long durations, like the 2MSL timers > that live in the networking code, or most especially the TIME_WAIT > timers). I haven't looked at this issue. How does it differ from the original System V implementation. Are you implying that we should use a different hash algorithm? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 8 23:29:39 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 6DC7437B401; Wed, 8 Aug 2001 23:29: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 f796TYl09253; Thu, 9 Aug 2001 00:29: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 f796TX127642; Thu, 9 Aug 2001 00:29:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108090629.f796TX127642@harmony.village.org> To: Yar Tikhiy Subject: Re: finger/fingerd & home directory permissions Cc: hackers@FreeBSD.ORG, security@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Aug 2001 02:08:31 +0400." <20010809020831.B44660@comp.chem.msu.su> References: <20010809020831.B44660@comp.chem.msu.su> Date: Thu, 09 Aug 2001 00:29: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 <20010809020831.B44660@comp.chem.msu.su> Yar Tikhiy writes: : The issue I'd like to submit to discussion is what way to choose: : a) Add a command-line option to finger(1) and fingerd(8) telling : them not to reveal user information if the user's homedir is : protected. : b) Similar to a), but hide such users by default. : c) Don't bother at all :-) d) $HOME/.nofinger 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 8 23:55:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id 66D6137B401; Wed, 8 Aug 2001 23:55:34 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NHPRWS08; Thu, 9 Aug 2001 10:47:07 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f796t2c93954; Thu, 9 Aug 2001 10:55:02 +0400 (MSD) (envelope-from yar) Date: Thu, 9 Aug 2001 10:55:02 +0400 From: Yar Tikhiy To: Warner Losh Cc: hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: finger/fingerd & home directory permissions Message-ID: <20010809105502.A92333@comp.chem.msu.su> References: <20010809020831.B44660@comp.chem.msu.su> <200108090629.f796TX127642@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: <200108090629.f796TX127642@harmony.village.org>; from imp@harmony.village.org on Thu, Aug 09, 2001 at 12:29:33AM -0600 Sender: owner-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 09, 2001 at 12:29:33AM -0600, Warner Losh wrote: > In message <20010809020831.B44660@comp.chem.msu.su> Yar Tikhiy writes: > : The issue I'd like to submit to discussion is what way to choose: > : a) Add a command-line option to finger(1) and fingerd(8) telling > : them not to reveal user information if the user's homedir is > : protected. > : b) Similar to a), but hide such users by default. > : c) Don't bother at all :-) > > d) $HOME/.nofinger It's just an equivalent of c) ;-) The top part of my message, which you skipped, I was speaking of the case when finger(1) couldn't access the home directory of a user and see the ".nofinger" file because of restrictive permission bits set on the directory. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 0:11:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 6533737B403 for ; Thu, 9 Aug 2001 00:11:54 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.111.Dial1.SanJose1.Level3.net [209.245.135.111]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA16931; Thu, 9 Aug 2001 00:11:39 -0700 (PDT) Message-ID: <3B723782.F55EDEBA@mindspring.com> Date: Thu, 09 Aug 2001 00:10:58 -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: Rolf Neugebauer Cc: Weiguang SHI , bright@mu.org, jeff@expertcity.com, freebsd-hackers@FreeBSD.ORG Subject: Re: timing question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Rolf Neugebauer wrote: > NB. for achieving higher timer resolutions you might find it > interesting to look at Soft-Timers at Rice [2]. Events are scheduled > at the usual timer interrupt frequency but the time wheels are also > checked at system-call and other interrupt times, thus, depending on > load, achieving finer grained timer resolutions. The TOCS paper, > referenced on that site, also describes a mixed approach between > Soft-Timers and hardware timers to achieve tighter delay bounds. I like most of Mohit Aron's papers, and Peter Druschel's work is pretty much landmark. The real problem with them is that their implementations are for very old versions of FreeBSD, or they are licensed with a pretty restrictive license that would prevent them from being incorporated in FreeBSD, or both. The soft timers aren't the only code, either. There are two different LRP implementations they have released in conjunction with the Scala server project; the one for FreeBSD 4.x is under a very restrictive license, while the other one is very old, and both of them are "graduate student code", i.e., they are not anywhere near usable in a production system. The LRP paper is the one I have been obliquely referencing with regard to receiver livelock avoidance in the thread "allocating at interrupt" (or something like that). Unfortunately, Mohit is now working for Zambeel on a Linux based product (I have a guess about it, actually), but they are still in stealth mode, so we aren't going to be seeing much from him for a while. Druschel is still working for Rice, last I heard, but has also formed a forward proxy cache company with some other academics, and they consistently win the performance numbers in the cache bakeoffs for forward proxy caches tested via the "polygraph" benchmark (polygraph is a typical "your product id a bad idea, so I am going to write something to kill it" benchmark, but everyone publishes numbers, so it's accepted as a figure of merit, even though it goes incredibly out of its way to first characterize how a forward proxy cache works, and then pick a pessimal usage pattern to bust it... "so there"). Most of the Scala ideas don't require 5 PhD's to understand, and someone well versed in the literature could implement them, with effort (for example, I've implemented LRP for FreeBSD 4.3-STABLE for the company I work for; LRP deals with one of the seven deadly receiver livelock issues). With HP selling a 10Gbit copper ethernet card on 64 bit PCI, even without the standards ratified (the optical geeks can't get their act together to get their components specified for that rate), it would be very easy to overwhelm your bus with DMA from the copper card, if you didn't handle each of the seven deadly issues in the livelock case correctly. For those who don't know the term, think "denial of service attack". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 0:32:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by hub.freebsd.org (Postfix) with SMTP id 9390437B62F for ; Thu, 9 Aug 2001 00:32:24 -0700 (PDT) (envelope-from fatalloy@yahoo.com) Received: from unknown (HELO alloy) (61.170.136.206) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 07:32:24 -0000 X-Apparently-From: Date: Thu, 09 Aug 2001 15:29:04 +0800 From: Fat Alloy To: freebsd-hackers@freebsd.org Subject: debug KLM Message-Id: <20010809152226.832E.FATALLOY@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.03 Sender: owner-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 try to use kgdb to debug a kld module, but always failed to set a breakpoint at the beginnig when the module is loaded. can you give me some advice please? thanks a lot! -- I am slim but they all call me fat alloy ^O^ Fat Alloy _________________________________________________________ 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 Thu Aug 9 1:39:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id A866D37B406; Thu, 9 Aug 2001 01:39:26 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.111.Dial1.SanJose1.Level3.net [209.245.135.111]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA02813; Thu, 9 Aug 2001 01:39:16 -0700 (PDT) Message-ID: <3B724C5D.6CDD0063@mindspring.com> Date: Thu, 09 Aug 2001 01:39:57 -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: Weiguang SHI Cc: grog@FreeBSD.org, bmilekic@technokratis.com, dillon@earth.backplane.com, zzhang@cs.binghamton.edu, freebsd-hackers@FreeBSD.org Subject: Re: Allocate a page at interrupt time References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Weiguang SHI wrote: > > I found an article on livelock at > > http://www.research.compaq.com/wrl/people/mogul/mogulpubsextern.html > > Just go there and search for "livelock". > > But I don't agree with Terry about the interrupt-thread-is-bad > thing, because, if I read it correctly, the authors themself > implemented their ideas in interrupt thread of the Digital Unix. Not quite. These days, we are not necessarily talking about just interrupt load limitations. Feel free to take the following with a grain of salt; but realize, I have personally achieved more simultaneous connections on a FreeBSD box than anyone else out there without my code in hand, and this was using gigabit ethernet controllers on modern hardware, and further, this code is in shipping product today. -- The number one way of dealing with excess load is to load-shed it before the load causes problems. In an interrupt threads implementaion, you can't really do this, since the only option you have is when to schedule a polling operation. This leads to several inefficiencies, all of which negatively impact the top end performance you are going to be able to achieve. Use of interrupt threads suffers from a drastically increased latency in reenabling of interrupts, and can generally only perform a single polling cycle, without running into the problem of not making forward progress at the application level (they run at IPL 0, which is effectively the same time at which NETISR is currently run). This leads to a tradeoff in increased interrupt handling latency (e.g. the Tigon II Gigabit ethernet driver in FreeBSD sets the Tigon II card firmware to coelesce at most 32 interrupts), vs. the transmit starvation problem noted in section 4.4 of the paper. It should also be noted that, even if you have not reenabled interrupts, the DMA engine on the card will still be DMA'ing data into your receiver ring buffer. The burst data rate on a 66MHz, 64 bit PCI bus is just over 4Mbits/S, and the sustainable data rate is much lower than that. This means a machine acting as a switch or firewall with two of these cards on board will not really have much time for doing anything at all, except DMA transfers, if they are run at full burst speed all the time (not possible). Running an application which requires disk activity will further eat into the available bandwidth. So this raises the spectre of DMA-based bus transfer livelock: not just interrupt based livelock, if one is scheduling interrupt threads to do event polling, instead of using one of the other approaches outlined in the paper. In the DEC UNIX case, they mitigated the problem by getting rid of the IP input queue, and getting rid of NETISR (I agree that these are required of any code with these goals). The use of the polling thread is really just their way of implementing the polling approach, from section 5.3. This does not address the problems I noted above, and in particular, does not address the latency vs. bus livelock tradeoff problem with modern hardware (they were using an AMD LANCE Ethernet chip; this was a 10Mb chip, and it doesn't support interrupt coelescing). They also assumed the use of a user space forwarding agent ("screend"): a single process. Further, I think that the feedback mechanism selected is not really workable, without rewriting the card firmware, and having a significant memory buffer on the card, something which is not available on the market yet today. This is because, in practice, you can't stop all incoming packet processing just because one user space program out of dozens has a full input queue that the user space program has not processed yet. It's not reasonable to ignore new incoming requests to a web server, or to disable card interrupts, or to (for example) drop all ARP packets until TCP processing for that one application is complete: their basic assumption -- which they admit, in section 6.6.1, is that the screend is the only application running on the system. This is simply not the case with a high traffic web server, a database system, or any other work-to-do-engine model of several process (or threads) with identical capability to service the incoming requests. Further, these applications use TCP, and thus have explicitly application bound socket endpoints, and there is no way to guarantee client load. We could trivially DOS attack an Apache server running SSL via mod_proxy, for example, by sending a flood of intentionally bad packets. The computation expense would keep its input queue full, and therefore, the feedback mechanism noted would starve the other Apache processes of legitimate input. There are other obvious attacks, which are no less damaging in their results, which attack other points in the assumption of a single process queue feedback mechanism. Their scheduler in section 7, which is in effect identical to the "fixed" scheduling class in SVR4 (which was used by USL to avoid the "move mouse, wiggle cursor" problem when using the UnixWare linker, which mmap'ed all object files, and then seeked all over in them, therefore thrashing all other pages out of the buffer cache, by giving the X server a fixed portion of the available CPU to thrash those pages back in -- a highly non-optimal fix), really only addresses CPU contention, at the cost of pessimizing the amount of CPU available to do packet processing when that's all the work ther is to do, and at the expense of "chatty" network apllications: precisely the sort of thing FreeBSD is being used for these days: NFS servers, HTTP servers, etc.; clearly, the quota was set from the perspective of the need to support an interactive user load which is not really common, nor expected in applications where FreeBSD is commonly used, these days. Section 7.1 notes this tangentially, in a discussion of NFS. Section 10 notes the differential rates of memory vs. CPU speed increase, and that their approach may have some problems; my opinion is that the polling approach is correct, and that there is probably room for something like a weighted fair share method for doing scheduling, and that using the 5.1 or 5.2 method, trather than the interrupt thread method in 5.3, would yield significantly better results in SMP and high speed interface systems that are limited not by interfaces or interrupts (per se), but by bis bandwidth (recent work at various Universities seems to confirm this opinion, FWIW). Overall, this is a seminal paper, and identifies almost every one of the important issues; and it admits where it may be wrong if things change in the future -- I would argue that things have changed. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 3:13:42 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 001AB37B401; Thu, 9 Aug 2001 03:13:26 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.111.Dial1.SanJose1.Level3.net [209.245.135.111]) by snipe.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA10558; Thu, 9 Aug 2001 03:13:21 -0700 (PDT) Message-ID: <3B726266.8026211C@mindspring.com> Date: Thu, 09 Aug 2001 03:13:58 -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: Greg Lehey Cc: void , freebsd-hackers@FreeBSD.org Subject: Re: Allocate a page at interrupt time References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <20010807221509.A24999@firedrake.org> <3B70E9DB.B16F409C@mindspring.com> <20010809115742.E73579@wantadilla.lemis.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 Greg Lehey wrote: > > Solaris hits the wall a little later, but it still hits the > > wall. > > Every SMP system experiences performance degradation at some point. > The question is a matter of the extent. IMO, 16 processors is not unreasonable, even with standard APIC based SMP. 32 is out of the question, but that's mostly because you can't have more than 32 APIC ID's in the current 32 bit processors, and still give one or more away to an IO APIC. 8-). > > On Intel hardware, it has historically hit it at the same 4 CPUs > > where everyone else tends to hit it, for the same reasons; > > This is a very broad statement. You contradict it further down. I contradict it for SPARC; I don't think I contradicted it for Intel, but am wiling to take correction... > > Solaris claims to scale to 64 processors while maintaining SMP, > > rather than real or virtual NUMA. It's been my own experience that > > this scaling claim is not entirely accurate, if what you are doing > > is a lot of kernel processing. > > I think that depends on how you interpret the claim. It can only mean > that adding a 64th processor can still be of benefit. The "4 processors" Intel claim is a "point of diminishing" returns, and is well enough known that it is almost passed into folklore (which might not bode well for finding people building boards with more, which would be unfortunate). My SPARC experience is likewise a "diminshing returns", where it becomes cheaper to buy another box to get the performance increment, than to stick more processors in the same box. It's definitely anecdotal on my part. > > On the other hand, if you are running a lot of non-intersecting user > > space code (e.g. JVM's or CGI's), it's not as bad (and realized that > > FreeBSD is not that bad in the same situation, either: it's just not > > as common in practice as it is in theory). > > You're just describing a fact of life about UNIX SMP support. "Practice vs. Theory"? Or the inevitability of UNIX SMP support having the performance characteristics it has most places? I don't buy the "we must live with the performance because it's UNIX" argument, if you meant the latter. > > It should be noted that Solaris Interrupt threads are only > > used for interrupts of priority 10 and below: higher priority > > interrupts are _NOT_ handled by threads (interrupts at a > > priority level from 11 to 15). 10 is the clock interrupt. > > FreeBSD also has provision for not using interrupt threads for > everything. It's clearly too early to decide which interrupts should > be left as traditional interrupts, and we've done some shifting back > and forth to get things to work. Note that the priority numbers are > noise. In this statement, they're just a convenient way to > distinguish between threaded and non-threaded interrupts. FreeBSD masks, Solaris IPLs. In context, this was meant to show why Solaris' approach is not directly translatable to FreeBSD. I really can't buy the idea that interrupt threads are a good idea for anything that can flood your bus or interrupt bandwidth, or have tiny/non-existant FIFOs, relative to the speeds they are being pushed; right now that means "might be OK for disks; not OK for really fast network controllers, not OK for sorta fast network controllers without a lot of adapter RAM, not OK for serial ports and floppies", at least in my mind. > I think somebody else has pointed out that we're very conscious of CPU > affinity. I think affinity isn't enough; I've expressed this to Alfred on a number of occasions already, when I see him in the hallway or at lunch. Dealing with the problem is kind of an all-or-nothing bid. > > In the 32 processor Sequent boxes, the actual system bus was > > different, and directly supported message passing. > > Was this better or worse? For the intent, much better. It meant that non-intersecting CPU/peripheral paths could run simultaneously. The Harris H1000 and H1200 had a similar thing (big iron real time systems used on Navy ships and at the college where Wes and I went to school). > > Also, the Sun system is still an IPL system, using level based > > blocking, rather than masking, and these threads can find > > themselves blocks on a mutex or condition variable for a > > relatively long time; if this happens, it resumes the previous > > thread _but does not drop its IPL below that of the suspended > > thread_, which is basically the Djikstra Banker's Algorithm > > method of avoiding priority inversion on interrupts (i.e. ugly). > > So you're saying we're doing it better? Long term priority lending is the real problem I'm noting; this is an artifact of context "borrowing", more than anything else (more below). I think the FreeBSD use of masking is better than IPL'ing, and is an obvious win in the case of multiple cards, since you can run multiple interrupt handlers at the same time, but wonder what will happen when/if it gets to UltraSPARC hardware. I think the Djikstra algorithm, in which contended resources are prereserved based on an anticipated need, tends to result in a lot of phantom contention: the resource may not end up being needed in the particular execution path (e.g. you grab the source and target directory vnode and the vnode of the file being renamed between the two, only to find a permission problem on a rename, etc.). Even success cases tend to have overly agressive resource grabbing, using this approach. It's like grabbing the BGL to do a "getpid" call. > > Finally, the Sun system "borrows" the context of the interrupted > > process (thread) for interrupt handling (the LWP). This is very > > similar to the technique employed with kernel vs. user space thread > > associations within the Windows kernels (this was one of the steps I > > was referring to when I said that NT had dealt with a number of > > scaling issues before it needed to, so that they would not turn into > > problems on 8-way and higher systems). > > This is also the method we're planning to use, as I'm sure you're > aware from previous messages on the -smp list. It's similar, but not identical to the NT approach. The NT approach actually necessitates marshalling locally heap and stack allocated objects between threads, rather than simply passing a pointer in a shared address space. This avoids the Sun problem with contention (on Sun, this is solved by special hardware help). On Intel, borrowing like this is potentially a big source of contention, unless you do what NT did; their solution is "a solution", but is probably not the best you could do; it introduces the need to be very careful about timer outcalls and externalized synchronization interfaces, since you might grab a resource, block, have a timer go off, have it "borrow" your context to execute, and then discover that it was permitted to grab a recursive mutex because it was the "same" kernel thread. We fought this problem when we ported the UFS/FFS code, and added our own Soft Updates implementation to Windows back in 1995, when running the syncd as a timer event. I know that it makes interrupt threads much less costly to use, but it seems fraught with peril. > > Personally, I think that the Sun system is extremely succeptible to > > receiver livelock (Network interrupts are at 7, and disk interrupts > > are at 5, which means that so long as you are getting pounded with > > network interrupts for e.g. NFS read or write requests, you're not > > going to service the disk interrupts that will let you dispose of > > the traffic, nor will you run the user space code for things like > > CGI's or Apache servers trying to service a heavy load of requests > > for content). > > Can you point to a system which does better, and explain why? LRP, from Rice University, for one. The first two approaches in the Mogul paper, for others (interrupt threads were the third and final approach in the Mogul paper). I've posted a brief analysis of the Mogul paper's use of interrupt threads as one of several potential solutions to the problem it was trying to addres,in a different message. What it boils down to in the context of FreeBSD on current and anticipated hardware is that livelock can come from bus contnetion, not just interrupt contention, and that the latency from using a polling thread (interrupt thread run after setting a "needs service" bit) in a situtation with something fast enough to cause problems is going to be unacceptably high, and the cure for that is fixed percentage scheduling, which will end up being non-optimal. > > I'm also not terrifically impressed with their callout mechanism, > > when applied to networking, which has a preponderance of fixed, > > known interval timers, but FreeBSD's isn't really any better, which > > it comes to huge numbers of network connections, since it will end > > up hashing 2/4/6/8/... into the same bucket, unordered, which means > > traversing a large list of timers which are not going to end up > > expiring (callout wheels are not a good thing to mix with fixed > > interval timers of relatively long durations, like the 2MSL timers > > that live in the networking code, or most especially the TIME_WAIT > > timers). > > I haven't looked at this issue. How does it differ from the original > System V implementation. Are you implying that we should use a > different hash algorithm? Their implementation is hierarchical and partitioned; if you crack the book, it's covered in detail starting around page 50. The main problem in FreeBSD comes when you look at the callout wheel size necessary to handle a lot of network connection timers at the same time. The idea behind the doubly linked list is predicated on the premise that timers are removed before firing in most cases: they are generally things like retransmit timers, etc.. This falls down in many of important places: o Even timers that are removed take six memory operations, compared to the one that was used for the previous TCP timer method. o Load that prevents other work (e.g. transmitter starvation or receiver livelock) exacerbates the situation, leading to catastrophic failure (work up to load X, then fall off a cliff to 0). o With a huge number of events, even if you are going to remove them later, you have to make the wheel very large, or the number of events in one bucket is going to get very large very fast, and since they are not ordered in increasing time-to-fire, you end up scanning all entries in a bucket o Making the wheel bigger takes more memory. o Making the entry list bigger increases the clock interrupt latency linearly (above some fixed cost for zero entries); if the list gets too big, you take more time scanning than there is until the next clock interrupt (meaning you _MUST_ increase the number of buckets). o If the number of buckets gets very large, the timer resolution is degraded. o The use of the timeouts is non-uniform for all subsystems; mostly networks end up sourcing (or sinking) traffic, which can be thought of as work-to-do requests; but this also means that there will be other timers in the list, which aren't so nicely removing themselves before they ever fire. o You could decide to "hint" about timers that were "expected" to be removed before firing, and stick them at the top of the buckets, but this still fails under load, and you are using a hash, and without knowledge of the other timer characteristics, you could easily put it in "the next bucket to be processed at the next clock interrupt". I think this can be addressed by setting aside a small set of lists of fixed interval timers: timers on these lists will all be the same duration, or they won't be on the list, they'll be sent to the callout wheel, which will remain in place. Lists might be 1MSL, 2MSL, TIME_WAIT timeout, FIN_WAIT_2 timeout, etc.. Events will be inserted via tail insertion... What this does is inherently time order the lists in increasing time to fire for a given interval. You can traverse the list heads in most cases very quickly, on the assumption that the timers will be removed before they can fire, and thus the head of the lists will not be ready to fire. If they are ready, you only need to traverse to the depth of the first one that is ready to fire: an (N/N+1)% "cache hit rate", for a depth of N. If not, you get a "miss" on the first entry, and go on to the next fixed interval list. This increases a tiny amount the fixed amount of overhead that you have in the timer code, while at the same time removing the network timeout processing overhead from the general case, where you have to scan _every_ bucket entry to get at the ones which are in the process of firing. I haven't really explored opportunistic timers in much depth, but it seems that they would benefit from this approach as well; for network processing, this approach pretty much negates the overall benefit of opportunistic timers, I think... criticisms welcome, of course. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 3:20: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id DAA6537B401 for ; Thu, 9 Aug 2001 03:19:59 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 15Umux-0000MR-0X; Thu, 9 Aug 2001 11:19:55 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f79AIe712454; Thu, 9 Aug 2001 11:18:40 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 9 Aug 2001 11:18:40 +0100 (BST) From: Doug Rabson To: Cc: Subject: Re: Newbus 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 Wed, 8 Aug 2001 janb@cs.utep.edu wrote: > I would very much like to know, exaclty which files comprise the code for > NEWBUS, excluding the drivers themselves.Can anyone help The external API is in sys/bus.h. The internal implementation is in sys/bus_private.h and kern/subr_bus.c. Interface definitions are scattered around the tree - the core interfaces DEVICE and BUS are in kern/device_if.m and kern/bus_if.m respectively. The 5.x version of newbus is based on the kobj system with api in sys/kobj.h and implementation in kern/subr_kobj.c. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 4:22:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iona.dcs.gla.ac.uk (iona.dcs.gla.ac.uk [130.209.240.35]) by hub.freebsd.org (Postfix) with ESMTP id 1FC5737B401 for ; Thu, 9 Aug 2001 04:22:21 -0700 (PDT) (envelope-from neugebar@dcs.gla.ac.uk) Received: from therese.dcs.gla.ac.uk ([130.209.241.134] helo=therese.dcs.gla.ac.uk.dcs.gla.ac.uk) by iona.dcs.gla.ac.uk with esmtp (Exim 3.13 #1) id 15UntM-0002eH-00; Thu, 09 Aug 2001 12:22:20 +0100 Received: by therese.dcs.gla.ac.uk.dcs.gla.ac.uk (8.11.3/Dumb) id f79BMFQ35472; Thu, 9 Aug 2001 12:22:15 +0100 (BST) To: Jeff Behl Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: timing question References: <0307F3737A2AD511A42200D0B7A071919A4043@dopey.corp.expertcity.com> From: Rolf Neugebauer Date: 09 Aug 2001 12:22:14 +0100 In-Reply-To: Jeff Behl's message of "Wed, 8 Aug 2001 10:21:20 -0700" Message-ID: Lines: 15 User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeff Behl writes: > thanks to all for the help with the timing question. Increasing the hz to > 400 (in param.c) allowed for granularity of 5ms, which is what we needed. > For those as unknowing as I was about unix timing, I ran across the > following url which explained why a setting of 400hz allows for a max > resolution of twice the tick amount (2.5ms).: > http://www.ripe.net/ripencc/mem-services/ttm/Notes/PAM2001/node6.html#SECTIO > N00061000000000000000 You don't need to modify param.c. Just add options HZ=400 # increase timer frequency to your kernel config file. Rolf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 8:36:48 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 9CFD637B407; Thu, 9 Aug 2001 08:36:39 -0700 (PDT) (envelope-from jon@enterprise.spock.org) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Thu, 9 Aug 2001 11:36:38 -0400 (EDT) (envelope-from jon)$ Date: Thu, 9 Aug 2001 11:36:38 -0400 From: Jonathan Chen To: net@freebsd.org, hackers@freebsd.org Subject: forwarding broadcast Message-ID: <20010809113638.A9519@enterprise.spock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x Sender: owner-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 FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not forwarded. For instance, if I have a FreeBSD router with interfaces 192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to 192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... but I haven't consulted all the RFC's so I'm not sure if some standard out there calls for it. In any case, the following patch creates a sysctl knob to turn on or off this feature (since it can be considered a security risk by some). I just want to ask around in case I turned out to be doing something incredibly evil. Comments? -Jon Index: in.h =================================================================== RCS file: /export/ncvs/src/sys/netinet/in.h,v retrieving revision 1.55 diff -u -r1.55 in.h --- in.h 2001/06/15 00:37:27 1.55 +++ in.h 2001/08/09 15:12:19 @@ -452,7 +452,8 @@ #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */ #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */ #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */ -#define IPCTL_MAXID 17 +#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */ +#define IPCTL_MAXID 18 #define IPCTL_NAMES { \ { 0, 0 }, \ Index: ip_input.c =================================================================== RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.174 diff -u -r1.174 ip_input.c --- ip_input.c 2001/06/23 17:17:58 1.174 +++ ip_input.c 2001/08/09 15:33:59 @@ -103,6 +103,10 @@ SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, &ipforwarding, 0, "Enable IP forwarding between interfaces"); +int ipforward_broadcast = 0; +SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast, CTLFLAG_RW, + &ipforward_broadcast, 0, "Enable broadcast packets when forwarding IP packets"); + static int ipsendredirects = 1; /* XXX */ SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, &ipsendredirects, 0, "Enable sending IP redirects"); @@ -1684,7 +1688,8 @@ } error = ip_output(m, (struct mbuf *)0, &ipforward_rt, - IP_FORWARDING, 0); + IP_FORWARDING| + (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0); if (error) ipstat.ips_cantforward++; else { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 8:50:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by hub.freebsd.org (Postfix) with ESMTP id E27E137B401; Thu, 9 Aug 2001 08:50:47 -0700 (PDT) (envelope-from bwithrow@BayNetworks.COM) Received: from mailhost.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA20243; Thu, 9 Aug 2001 08:48:15 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA13087; Thu, 9 Aug 2001 08:48:12 -0700 (PDT) Received: from baynetworks.com (tuva [192.32.150.102]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id LAA04570; Thu, 9 Aug 2001 11:50:20 -0400 for Message-Id: <200108091550.LAA04570@pobox.engeast.BayNetworks.COM> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: hackers@freebsd.org, questions@freebsd.org Subject: Re: Ypbind malfunction on 4.x In-Reply-To: Message from Peter Pentchev of "Tue, 07 Aug 2001 18:27:16 +0300." <20010807182716.B465@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 11:50:20 -0400 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG roam@ringlet.net said: :- I think that there has been quite a lot of work on ypbind recently. :- Try updating to 4.3-STABLE (actually 4.4-PRERELEASE now), there were :- several patches in that area in the past week or two. :- Or alternatively, wait for 4.4-RELEASE about the end of August. Also, I think I've found a work-around: If I configure ypbind to use the -m and -S options ("manycast" versus broadcast) the problem seems to go away. Thanks! (I've CC'd questions because of the work-around info above.) -- Robert Withrow -- (+1 978 288 8256, ESN 248) BWithrow@NortelNetworks.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 8:54:14 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 58DF337B401; Thu, 9 Aug 2001 08:53:26 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f79FrLf10409; Thu, 9 Aug 2001 11:53:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 9 Aug 2001 11:53:20 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: developers@FreeBSD.org Cc: hackers@FreeBSD.org Subject: FreeBSD Status Report, July 2001 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 FreeBSD Monthly Status Report, July 2001 Robert Watson Introduction Last month's status report was apparently a great success: I received countless e-mails with comments, questions, and suggestions. I've tried to incorporate any suggestions and address any problems from these e-mails in this month's report, which captures a far more extensive snapshot of FreeBSD activity in the last month. Unlike last month's report, it does a better job of reflecting non-development activity, such as on-going conference planning, documentation, and so on. This is a trend I hope to see improve in future months as well. On the topic of conferences, in the future I'd like to report more on publication activities relating to FreeBSD, including online journals with articles relating to FreeBSD, paper journals, conference papers, and so on. Likewise, I would be interested in including references to Call for Papers relating to FreeBSD. I'll take this opportunity to plug both registration and paper submission for BSDCon Europe in November, which has status included in this report, and for the general BSD Conference being hosted by USENIX in February. Your attendance and submissions make these conferences "happen", and promote FreeBSD as a platform for new research, feature development, and application products. Work of extremely high calibre is performed on FreeBSD, and we need to get the word out. Submission for Future Editions Next month, we're maintain much the same submission requirements: reports should be one or two paragraphs long, sent by e-mail, and approximate the layout of the entries this month (Project, Contact, URL, and text). I'll send out reminders again over the week before the deadline, with more specific instructions. An area where I'd like to explore improvement lies in the coordination of related status reports for larger projects, such as new architectural work or platform ports. This might even have the effect of encouraging communication within these projects :-). I'd like to continue to focus on pulling in a broader range of groups and their activities, including the Security Officer, Release Engineer, and Core Team. Projects The following projects submitted summaries for the July 2001 report: ACPI ARM Port BIND 9 binup BSDCon Europe CAM "Close a PR drive" Documentation Project Fibre Channel Support Hardware Watchpoints in the Kernel Debugger ifconfig support for IEEE 802.11 wireless devices jailNG FreeBSD Java Project jpman project Kernel Summit - Usenix 2001 KSE threading the kernel FreeBSD Monthly Development Status Reports NetBSD rc.d port Netgraph ATM network device cloning Next Generation POSIX threads (NGPT) OLDCARD upgrade to support PCI cards Open Runtime Platform (ORP) OpenPackages PAM PowerPC Port PPP IPv6 Support Porting ppp to hurd & linux pppoed PRFW - Hooks within the FreeBSD kernel SCSI Tape Support SMPng SMPng mbuf allocator sparc64 port FreeBSD/sparc64 kernel loader SYN cache implemetation for FreeBSD TrustedBSD Project Status Reports Project: ACPI Contact: Mike Smith ACPI (Advanced Configuration and Power Interface) is an industry standard which obsoletes APM, Intel MPS, PnPBIOS, and other Intel PC firmware interface standards. It is also used on the IA64 platform. More information on ACPI is available at http://developer.intel.com/technology/iapc/acpi The FreeBSD ACPI subsystem project is based heavily on the Intel ACPI Component Architecture. This status report outlines the current state of the project; future updates will focus on changes as they occur. The Intel ACPI interpreter is fully integrated, although bugs are still coming out of the woodwork occasionally. - PCI bus detection and interrupt routing are functional, but power management interaction will require work on the core PCI subsystem. - Non-PCI motherboard peripheral probing is implemented, but believed to have problems on some systems. - A power policy manager has been implemented. The initial policy manager has two modes, "performance" and "economy". - CPU speed throttling is integrated with the platform power policy. - System thermal monitoring is implemented, but fan control is believed to have problems. - Pushbutton suspend and power-off is implemented. - System time-keeping using the ACPI timer is supported. - Battery status monitoring is implemented. Work is ongoing in the following areas: - System suspend and resume. - Timekeeper accuracy/reliability. - Power profiles. - User-level management interfaces. - PCI power management. - Bug-hunting. Project: ARM Port Contact: Stephane E. Potvin The ARM port is currently going pretty well. The kernel is compiling and is able to boot to the point where it panics trying to initialize the network subsystem. The current reference platform is the Netwinder but this may change as many people expressed interest in a more broadly available platform. Things that need to be done before it can get further includes adding footbridge, timer and interrupt supports. The pmap module is not completed yet either. Project: BIND 9 Contact: Doug Barton , Jeroen Ruigrok Now that BIND 8.2.4 is finally imported the time has come to look at getting BIND 9 imported into CURRENT. The current idea is to have it imported alongside BIND 8 so that people can play with either one until all import problems have been taken care of and people have tested it a bit. Project: binup Contact: Eric Melville Although gaining a new name, the project has been at a standstill due to both resource availability during the move between BSDi and Wind River, and other commitments of the developers. The project should obtain an official mailing list, as well as return to an active state after the dust settles. Project: BSDCon Europe URL: http://www.bsdconeurope.org Contact: Paul Richards , Josef Karthauser The conference will take place at the Thistle Hotel, Brighton, UK from 9-11 November 2001. The aim of the conference is to provide a focal point for European users and developers of all the BSD derived operating systems. The format will be similar to other conferences, with 2 days of technical sessions over the Saturday and Sunday. We'll be finalizing the schedule towards the end of the month and anybody who is interested in doing a talk should contact us ASAP. There are no restrictions on the use of talks, if it's been done before we may still be interested in having it presented to an European audience, and we make no claims to the talks so speakers are free to present the talks again at other conferences. We're also still looking for sponsors. We had 80 pre-registrations in the first week so we're expecting a good turnout. Project: CAM Contact: mjacob@freebsd.org, gibbs@freebsd.org, ken@freebsd.org The new CAM transport code is starting to get supported in more HBAs and to get refined so that it does the intended per-protocol support. No progress on doing any SMPNG work for CAM has been made yet. This is a fairly high priority. Project: "Close a PR drive" URL: http://phk.freebsd.dk/Gnats/ Contact: phk@FreeBSD.org Thanks to various outstanding individual efforts, we are now down to just below 2300 open bug-reports. This means that we have fought our way back to the level we had around march 2000. Project: Documentation Project URL: http://www.FreeBSD.org/docs.html URL: http://www.FreeBSD.org/docproj/index.html Contact: Documentation Project Work continues (in large part sponsored by WRS) on updating the Handbook ready for the second print edition. There has been a flurry of activity in this area recently, and the ToDo list can be seen at http://www.freebsd.org/docproj/handbook.html Dima and others are doing a stellar job of keeping up with the steady flow of incoming PRs relating to the documentation project. The Developers' Handbook, http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.html is a year old; it contains a wealth of useful content for developers developing on, or for, FreeBSD. As ever, more contributions are always required, not only for the developers' handbook, but for all of the FreeBSD documentation set. Project: Fibre Channel Support Contact: mjacob@feral.com The basic design hasn't changed and this project mainly is in the phase of continued hardening and test case development. The next major feature will be to fully integrate into the new CAM TRAN code and to fully support on the fly device addition and removal. The only HBA supported is QLogic at this time. Future support for the QLogic line is planned to have 2300 (2Gb) and IP support before October. Project: Hardware Watchpoints in the Kernel Debugger Contact: Brian Dean Hardware watchpoints are now available for kernel debugging on the IA32 (i386) architecture. One can now set hardware watchpoints using the new ddb command 'hwatch', which is analogous to the existing 'watch' command. Alternatively, if greater flexibility is required, direct access to the debug registers is available using the ddb 'set' command which allows complete control over the processor hardware debug facilities. Hardware watchpoints are very useful in tracking down those elusive memory overwrite bugs in the kernel. Hardware watchpoints can even be used to set a code breakpoint in ROM, which is commonly found in embedded systems. Project: ifconfig support for IEEE 802.11 wireless devices Contact: Brooks Davis Support for configuring IEEE 802.11 wireless devices via ifconfig has been committed to -current and -stable. It contains most of the functionality needed to configure an wireless device. Some missing features are being worked on including integrated support for DHCP so a single entry in /etc/rc.conf can be used to fully configure a wireless device on a DHCP lan and setting the CTS/RTS threshold. Currently the an(4) and wi(4) drivers are supported in -current and -stable with the awi(4) device supported in -current. Further work is needed to support Frequency Hopping devices such as ray(4). Project: jailNG Contact: Robert Watson jailNG is a from-scratch rewrite of the popular jail(8) service, focusing on improved management functions, as well as more fine-grained configurability. An initial prototype has been written, based on explicitly named and configured jails, and work is proceeding on userland integration. Currently, it's not clear if the timeline for this will be 5.0-RELEASE, or 5.1-RELEASE. Project: FreeBSD Java Project URL: http://www.freebsd.org/java/ Contact: glewis@eyesbeyond.com The main development in the FreeBSD Java Project over the last month was the release of an initial "Developers Only" patch set for the JDK 1.3.1. Since that release progress had been made towards a much more usable alpha quality patch set which is likely to be turned into a port, as per the current JDK 1.2.2 patch set. This new patch set will feature a number of bugfixes, which essentially get the JDK to a working state for early adopters, and an initial implementation of "native threads" based on FreeBSD's userland pthreads. Unfortunately this implementation isn't fully functional, but is included in the hope of more getting more eyeballs on the code (particularly experience pthread programmers). We'd also like to welcome Fuyuhiko Maruyama-san as a new committer, the usual punishment for too many good patches. Project: jpman project URL: http://www.jp.FreeBSD.org/man-jp/ (in Japanese) Contact: man-jp@jp.FreeBSD.org We have been working to provide Japanese version of FreeBSD online manuals, since 1996. Currently, RELENG_4 manuals are based. Translated versions are placed on doc/ja_JP.eucJP/man and provided to users using ports/japanese/man-doc. Also, we discuss about related commands (e.g. ports/japanese/man and ports/japanese/groff). Project: Kernel Summit - Usenix 2001 URL: http://www.FreeBSD.org/~jhb/summit/usenix01/ Contact: John Baldwin The first FreeBSD kernel summit meeting was held June 29-30, 2001 in Boston, MA at the Usenix 2001 Annual Technical Conference. Links to a variety of files are posted on the web site. Note: I (jhb) am still working on writing up a general summary of the meeting. When that is completed it will be posted here and mailed to the -hackers mailing list. Project: KSE threading the kernel URL: http://people.freebsd.org/~jasone/kse/ Contact: julian@elischer.org I'm working on multithreading the kernel. So far I have over 400KB of diffs relative to todays -current (I'm keeping my tree updated with changes as they occur rather than get hit with a big update at the end). I have split the proc structure and am changing most of the kernel to pass around a thread identifier instead of a proc structure. The following interfaces have been changed so far: device devsw entries vfs calls mutexes events system calls scheduler + a lot of code in between. I have still a lot of work to go with a lot of "dumb editing" (s/struct proc \*p/struct thread \*td/) usually I change a few items and then fix everything that breaks when I try compile it. I'd like to check it in on a branch so others can help the editing but haven't worked out the best way to do it yet. I have implemented changes to the scheduler so that kse's are scheduled instead of processes, and threads sleep, letting the kse pick up a new thread. but it's not anywhere ready yet (heck it doesn't compile yet :-) Note that I have not yet updated the document listed above.. everywhere it mentions "ksec" or "KSE-context", the code uses the word "thread". I will update it soon as Jason has sent me the source. Project: FreeBSD Monthly Development Status Reports URL: http://www.FreeBSD.org/news/status/ Contact: Robert Watson , Chris Costello The FreeBSD Monthly Development Status Report aims to keep users and developers up-to-date on the latest goings-on in the FreeBSD project by providing summaries of each project and its status. At the time of this writing, the July 2001 status report is being prepared and is very near release. The FreeBSD Web site now has a Status Reports section, which, when the July 2001 report is released, will be updated to include a link to an HTML-ified version. Project: NetBSD rc.d port URL: http://groups.yahoo.com/group/FreeBSD-rc Contact: dougb@FreeBSD.org, sheldonh@FreeBSD.org The NetBSD rc.d port aims to improve the FreeBSD startup process by porting Luke Mewburn's rc.d work from NetBSD to FreeBSD. This will score FreeBSD startup and shutdown dependencies without losing the traditional and much loved monolithic configuration file system. Luke Mewburn's USENIX paper and slides on the system as implemented in NetBSD are available here: http://groups.yahoo.com/group/FreeBSD-rc/message/3 Interested parties are urged to study this material before joining the discussion list. The intention at this stage is to decide on an approach that will ensure that the differences between the NetBSD rc.d system and the system as ported to FreeBSD will be kept to a minimum. This will probably involve discussions with Luke around those areas of the system that are identified as areas for potential improvement. Project: Netgraph ATM Contact: Hartmut Brandt The goal of this project is the implementation of ATM signaling and other ATM protocols by means of the netgraph(4) framework. This should provide an easily extendible architecture for using ATM on FreeBSD. Currently the full UNI4.0 stack (except for the LIJ capability) has been implemented, including ILMI and a first version of the ATM Forum API for UNI. An implementation of Classical IP over ATM is also available. Drivers have been implemented for the Fore PCA200E and Fore HE-155 cards. Project: network device cloning Contact: Brooks Davis Network device cloning support has been imported from NetBSD. This allows virtual devices to be allocated on demand rather then being statically allocated at compile time. Our implementation differs slightly from that of NetBSD's in that we allow both the creation of specific devices (i.e. gif0) and arbitrary devices instead of just allowing specific devices. Currently, the only device in the tree which has been converted is the gif(4) device which has been converted in both -current and -stable. Work is ongoing to convert all other virtual network devices with work in progress on faith, stf, and vlan interfaces. In general this conversion is accompanied by appropriate modifications to make these devices fully modular. Project: Next Generation POSIX threads (NGPT) URL: http://oss.software.ibm.com/developerworks/opensource/pthreads/ Contact: arun@sharmas.dhs.org Porting NGPT (next generation pthreads) to FreeBSD NGPT is an effort led by IBM engineers to implement MxN threads (also known as many user threads to one kernel thread mapping) on Linux. I have ported it to FreeBSD to use rfork(2). The port is right here: http://www.freebsd.org/cgi/query-pr.cgi?pr=29239 Project: OLDCARD upgrade to support PCI cards URL: http://people.freebsd.org/~imp/oldcard-status.html Contact: imp@village.org Funded by: Monzoon Networking, LLC This month has been a month of concentration and consolidation. Much of the changes from current have been migrating into stable. I've improved power support, suspend/resume interactions, interrupt handling, and ability to work after windows/NEWCARD has run. Interrupt routing continues to be a locking issue for a complete MFC. Current patches are available at the above website. I'm racing to get this done before 4.4 is released. Project: Open Runtime Platform (ORP) URL: http://www.intel.com/research/mrl/orp/ Contact: arun@sharmas.dhs.org, orp@egroups.com Information on Intel ORP - a BSD licensed Java VM is right here: http://www.intel.com/research/mrl/orp/ A FreeBSD patch has been tested to work with NGPT and submitted to the ORP project. The patch is available here: http://www.sharma-home.net/~adsharma/projects/orp/orp-freebsd-1.0.5.patch.txt.gz There are some issues to be ironed out to make it work with FreeBSD's default (user level) pthread implementation. Project: OpenPackages URL: http://openpackages.org/ OpenPackages intends to create a software packaging system that will allow third-party programs to be installed, without operating system dependent changes, on as many platforms as are feasible. OpenPackages was originally based on code from the BSD ports systems, and has been improved and extended by developers of many heritages. The OpenPackages Project is pleased to release the Milestone 2 codebase. This release contains a working package building system and a single test package. OP currently is known to build on certain instances of the following operating systems: FreeBSD, HP/UX, IRIX, Linux (Debian, Red Hat, Suse, Mandrake, TurboLinux, Caldera, etc.), NetBSD, OpenBSD, Solaris Project: PAM Contact: Mark R V Murray (First report) Large cleanup and extension of FreeBSD PAM modules. All modules are to be documented, consistent in style (style(9) used) and as complete as possible WRT functionality. Mostly done. Project: PowerPC Port Contact: benno@FreeBSD.org We now have the rudiments of device support. We have a nexus driver for OpenFirmware machines, along with support for the Apple UniNorth PCI/AGP host bridge. I'm currently trying to get the USB hardware working so that I can get closer to having a console driver independent of OpenFirmware, then I'll be trying to get the system to get to single-user mode using NFS. Project: PPP IPv6 Support Contact: brian@freebsd-services.com Work has begun, but nothing has yet been committed. The NCP addresses used by ppp have been abstracted and initial support has been added to the filter set for ipv6 addresses. NCP negotiation hasn't yet been started. Project: Porting ppp to hurd & linux Contact: brian@Awfulhak.org Patches have been submitted to get ppp working under HURD, and mostly under Linux. There are GPL copyright problems that need to be addressed. Project: pppoed Contact: brian@freebsd-services.com Making pppoed function in a production environment. Most of the work is complete and committed. Additional work includes adding a -l option where ``-l label'' is shorthand for ``-e exec ppp -direct label'' and discovering why rogue child processes are being left around. Project: PRFW - Hooks within the FreeBSD kernel Contact: Evan Sarmiento PRFW is a set of hooks which I have integrated into the FreeBSD kernel. This allows modules to easily intercept system calls with less overhead. It also supports per-pid restrictions, which means, one process may not be able to use X function in Y manner, but another process may. Progress: I was working on this in 4.3-RELEASE, but now I'm merging it into current. I will be submitting a patch to the mailing lists in about a week. Project: SCSI Tape Support Contact: mjacob@feral.com This driver is currently not working well under -current and is undergoing some work at this time. No major design or feature changes are planned. There was some notion of adding TapeAlert support, but HP supports that as a binary product via a user library and it was felt that it'd be more politically prudent to leave it alone. Project: SMPng Contact: Peter Wemm , John Baldwin Development: In the 'smpng' p4 branch there is code to make the ast() function loop to close the race when an AST is triggered while we are handling previously triggered AST's. In the 'jhb_preemption' p4 branch work is being done to make the kernel fully preemptive. It is reportedly stable on UP x86, but SMP x86 locks up, UP alpha has problems during shutdown and can recurse indefinitely until it exhausts its stack. Management: We are using a perforce repository for live development work, which can track multiple separate long-lived works-in-progress and collaborate between multiple developers at the same time on the same change set. FreeBSD-current is being imported into p4 hourly, for easy tracking of the moving -current tree. I haven't written up a good primer yet, but we're able to open this up to the general developer community. NEWCARD work looks like it will be done here too. Perforce is ideal for tracking this sort of long-lived project without having to resort to passing patches around. KSE work is now being checked into a kse p4 branch - thanks Julian! KSE work is focusing on getting the main API changes into the base tree well before 5.0. Project: SMPng mbuf allocator URL: http://people.freebsd.org/~bmilekic/code/mb_slab/ Contact: Bosko Milekic mb_alloc is a specialized allocator for mbufs and mbuf clusters. It offers various important advantages over the old mbuf allocator, particularly for MP machines. Additionally, it is designed with the possibility of important future enhancements in mind. The mb_alloc code has been committed to -CURRENT a month ago and appears to be holding up well. Prior to committing it, preliminary performance measurements were done merely to ensure that it is not significantly worse than the old allocator, even with Giant still in place. Results were promising [http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html] - also see jlemon's results (link at the bottom of accompanying text). Since the commit, Matt Jacob has provided useful feedback and bugfixes. Work is now being done to re-enable mbtypes statistics and make appropriate changes to netstat(1) and systat(1). Project: sparc64 port Contact: Jake Burkholder The sparc64 port has been committed to the FreeBSD repository. As such further development will occur in cvs, rather than as a separately maintained patch set. Significant progress has been made since the last status report, including; support for kernel debugging with ddb, much more complete pmap support, support for context switching and process creation, and filling out of important machine dependent data structures. Thomas Moestl has shown a strong interest in working on the port and is in the process of implementing support for saving and restoring a process's floating point context. I look forward to working with him and any other developers that happen to fall out of the wood works. Project: FreeBSD/sparc64 kernel loader Contact: Robert Drehmel The sparc64 loader is functional enough to boot an ELF binary from an UFS filesystem using the existent openfirmware library, which has been revised to work flawlessly on 32-bit and 64-bit architectures. Support for netbooting and modules will be implemented next, followed by a better openfirmware mapping strategy. Project: SYN cache implemetation for FreeBSD Contact: Jonathan Lemon This project brings a SYN cache implementation to FreeBSD, in order to make it more robust to DoS attacks. A SYN cookie approach was considered, but ultimately rejected because it does not conform to the TCP protocol. The SYN cache will work with T/TCP, IPV6 and IPSEC, and the size of each cache element is currently is less than 1/5th the size of a normal TCP control block. Project: TrustedBSD Project URL: http://www.TrustedBSD.org/ Contact: Robert Watson It's been a busy month, with a number of relevant news items. Not least important is that NAI Labs was awarded a $1.2M contract from the US Defense Advanced Research Projects Agency (DARPA) to work on a variety of components relevant to the TrustedBSD Project, including support for pluggable security models, and supporting features such as improving the extended attributes implementation, simple crypto support for swap and file systems, documentation, and much more. On the features side, progress continues on Mandatory Access Control, object labeling, and improving the consistency of kernel access control mechanisms--in particular, with regard to inter-process authorization and credential management. Work has begun on porting LOMAC, NAI Labs' Low-Watermark Mandatory Access Control scheme, from Linux to FreeBSD, and it has been re-licensed under a BSD license. We hope to have an initial port complete in time for 5.0-RELEASE later this year. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:19:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from www.estart.ru (www.eStart.ru [212.188.13.155]) by hub.freebsd.org (Postfix) with ESMTP id BABF537B401 for ; Thu, 9 Aug 2001 09:19:33 -0700 (PDT) (envelope-from smail@eStart.ru) Received: from 10.0.0.2 (KGTRK.RadioLAN.krs.ru [195.161.70.233]) by www.estart.ru (8.10.1/WWW_ESTART) with ESMTP id f79GJHD67169 for ; Thu, 9 Aug 2001 20:19:18 +0400 (MSD) Date: Wed, 1 Aug 2001 00:17:42 +0700 From: smail X-Mailer: The Bat! (v1.48c) UNREG / CD5BF9353B3B7091 Reply-To: smail X-Priority: 3 (Normal) Message-ID: <15541463687.20010801001742@estart.ru> To: freebsd-hackers@FreeBSD.org Subject: need help Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello freebsd-hackers, i need some help. my problem is about memory limit in mmap function. i can't mmap files infinitely, after some number of file mmaped in memory i've got an error, probably causing memory limit of 2 or 4 Gb. can you help me? my platform is FreeBSD 4.3/i386 [128Mb RAM, 4Gb swap]. -- with best regards, smail mailto:smail@estart.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:21: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 4B2E537B401; Thu, 9 Aug 2001 09:21:02 -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 f79GKxI16455; Thu, 9 Aug 2001 09:20:59 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 9 Aug 2001 09:20:55 -0700 (PDT) From: Matthew Jacob Reply-To: To: Jonathan Chen Cc: , Subject: Re: forwarding broadcast In-Reply-To: <20010809113638.A9519@enterprise.spock.org> Message-ID: <20010809092010.M69994-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 I haven't consulted the RFCs either, but, ahem, I thought this was a major point of netmasks and routers and why multicast was invented- to keep broadcasts from clogging the world. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:24: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bilver.wjv.com (dhcp-1-3.n01.orldfl01.us.ra.verio.net [157.238.210.3]) by hub.freebsd.org (Postfix) with ESMTP id 11FC137B401; Thu, 9 Aug 2001 09:23:54 -0700 (PDT) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.1/8.11.1) id f79GNrr32952; Thu, 9 Aug 2001 12:23:53 -0400 (EDT) (envelope-from bill) Date: Thu, 9 Aug 2001 12:23:52 -0400 From: Bill Vermillion To: Jonathan Chen Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: forwarding broadcast Message-ID: <20010809122352.B32613@wjv.com> Reply-To: bv@wjv.com References: <20010809113638.A9519@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: <20010809113638.A9519@enterprise.spock.org>; from jon@FreeBSD.ORG on Thu, Aug 09, 2001 at 11:36:38AM -0400 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-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 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach: > On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses > are not forwarded. For instance, if I have a FreeBSD router with > interfaces 192.168.1.1 and 192.168.2.1, and I send packets from > 192.168.1.2 to 192.168.2.255, the packets are dropped to the > floor. IMO, this is wrong... But the question now is - what is the netmask on these interfaces.? That will make a difference. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:27:43 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 3FD2437B407; Thu, 9 Aug 2001 09:27:39 -0700 (PDT) (envelope-from jon@enterprise.spock.org) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Thu, 9 Aug 2001 12:27:10 -0400 (EDT) (envelope-from jon)$ Date: Thu, 9 Aug 2001 12:27:10 -0400 From: Jonathan Chen To: Matthew Jacob Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: forwarding broadcast Message-ID: <20010809122710.F9519@enterprise.spock.org> References: <20010809113638.A9519@enterprise.spock.org> <20010809092010.M69994-100000@wonky.feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <20010809092010.M69994-100000@wonky.feral.com>; from mjacob@feral.com on Thu, Aug 09, 2001 at 09:20:55AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Aug 09, 2001 at 09:20:55AM -0700, Matthew Jacob wrote: > > I haven't consulted the RFCs either, but, ahem, I thought this was a major > point of netmasks and routers and why multicast was invented- to keep > broadcasts from clogging the world. It would be nice if all applications supported multicast. It would be even nicer if I could figure out why mrouted isn't doing what it's supposed to do on this machine, but that's a whole different problem... I might ask for help on that one if I still can't figure it out after some debugging... -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:31:14 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 A4C1637B406; Thu, 9 Aug 2001 09:31:08 -0700 (PDT) (envelope-from jon@enterprise.spock.org) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Thu, 9 Aug 2001 12:30:56 -0400 (EDT) (envelope-from jon)$ Date: Thu, 9 Aug 2001 12:30:56 -0400 From: Jonathan Chen To: bv@wjv.com Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: forwarding broadcast Message-ID: <20010809123056.G9519@enterprise.spock.org> References: <20010809113638.A9519@enterprise.spock.org> <20010809122352.B32613@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <20010809122352.B32613@wjv.com>; from bill@wjv.com on Thu, Aug 09, 2001 at 12:23:52PM -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 Thu, Aug 09, 2001 at 12:23:52PM -0400, Bill Vermillion wrote: > On Thu, Aug 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach: > > > On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses > > are not forwarded. For instance, if I have a FreeBSD router with > > interfaces 192.168.1.1 and 192.168.2.1, and I send packets from > > 192.168.1.2 to 192.168.2.255, the packets are dropped to the > > floor. IMO, this is wrong... > > But the question now is - what is the netmask on these interfaces.? > That will make a difference. These are both class C networks, and their netmask is specified accordingly (/24). I'm pretty sure my setup is correct here. -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:36:18 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 78CD937B401; Thu, 9 Aug 2001 09:36:10 -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 f79GZfI16709; Thu, 9 Aug 2001 09:35:44 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 9 Aug 2001 09:35:37 -0700 (PDT) From: Matthew Jacob Reply-To: To: Robert Withrow Cc: , Subject: Re: Ypbind malfunction on 4.x In-Reply-To: <200108091550.LAA04570@pobox.engeast.BayNetworks.COM> Message-ID: <20010809093519.R69994-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 BTW- the -m or not -m dance has come and gone with *BSD ypbind for the last 4 years. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:45:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id E0F3337B401; Thu, 9 Aug 2001 09:45:16 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 4F5671E030; Thu, 9 Aug 2001 12:45:16 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA00088; Thu, 9 Aug 2001 12:45:15 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA03207; Thu, 9 Aug 2001 09:45:15 -0700 (PDT) Message-Id: <200108091645.JAA03207@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jon@freebsd.org Subject: Re: forwarding broadcast Cc: net@freebsd.org, hackers@freebsd.org Date: Thu, 9 Aug 2001 09:45:14 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-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 FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not >forwarded. "smurf" attacks love using broadcast forwarders. RFC 2644 says: > A router MAY have an option to enable receiving network-prefix- > directed broadcasts on an interface and MAY have an option to > enable forwarding network-prefix-directed broadcasts. These > options MUST default to blocking receipt and blocking forwarding > of network-prefix-directed broadcasts. So, your patch just adds the mentioned option -- which I'm fine with, as long as the default is 0 as the RFC requires... Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 9:47:59 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 570BF37B403 for ; Thu, 9 Aug 2001 09:47:56 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f79GluN47961 for hackers@FreeBSD.ORG; Thu, 9 Aug 2001 12:47:56 -0400 (EDT) (envelope-from bicknell) Date: Thu, 9 Aug 2001 12:47:56 -0400 From: Leo Bicknell To: hackers@FreeBSD.ORG Subject: Re: forwarding broadcast Message-ID: <20010809124756.A47552@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , hackers@FreeBSD.ORG References: <20010809113638.A9519@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: <20010809113638.A9519@enterprise.spock.org>; from jon@FreeBSD.ORG on Thu, Aug 09, 2001 at 11:36:38AM -0400 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 This is called a 'directed broadcast'. In the early days there was no talk of this sort of packet, leading to the assumption that it should work as you expect. Many network management packages did (and some still do) use directed broadcast pings to try and find all hosts on managed subnets. Due mainly to smurf amplification (send a directed broadcast ping to a full subnet with a spoofed source to flood that box) ISP's (and more slowly) router vendors have turned this feature off in almost all Internet networks. The Cisco interface command is 'no ip directed-broadcast' on an interface. I would recomend strongly against ever turning it on, in any enviornment. That said, it does not seem unreasonable to provide the knob, since all major router vendors do and FreeBSD should be as flexable as any commercial product. -- 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 Thu Aug 9 9:57:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bilver.wjv.com (dhcp-1-111.n01.orldfl01.us.ra.verio.net [157.238.210.111]) by hub.freebsd.org (Postfix) with ESMTP id 5E53E37B403; Thu, 9 Aug 2001 09:57:49 -0700 (PDT) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.1/8.11.1) id f79Gvmd33221; Thu, 9 Aug 2001 12:57:48 -0400 (EDT) (envelope-from bill) Date: Thu, 9 Aug 2001 12:57:47 -0400 From: Bill Vermillion To: Jonathan Chen Cc: bv@wjv.com, net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: forwarding broadcast Message-ID: <20010809125747.A33178@wjv.com> Reply-To: bv@wjv.com References: <20010809113638.A9519@enterprise.spock.org> <20010809122352.B32613@wjv.com> <20010809123056.G9519@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: <20010809123056.G9519@enterprise.spock.org>; from jon@FreeBSD.ORG on Thu, Aug 09, 2001 at 12:30:56PM -0400 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-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 09, 2001 at 12:30:56PM -0400, Jonathan Chen thus sprach: > On Thu, Aug 09, 2001 at 12:23:52PM -0400, Bill Vermillion wrote: > > On Thu, Aug 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach: > > > > > On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses > > > are not forwarded. For instance, if I have a FreeBSD router with > > > interfaces 192.168.1.1 and 192.168.2.1, and I send packets from > > > 192.168.1.2 to 192.168.2.255, the packets are dropped to the > > > floor. IMO, this is wrong... > > But the question now is - what is the netmask on these interfaces.? > > That will make a difference. > These are both class C networks, and their netmask is specified > accordingly (/24). I'm pretty sure my setup is correct here. So they are two separate networks therefore a broadcast for one should not go the other. If on the other hand you netmask was 255.255.252.0 then 192.168.0.x thru 192.168.3.255 would be part of the same network and you'd expect a broadcast to propagate. At least this is how I understand how it works, and I could be wrong. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 10: 5:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 4958137B403; Thu, 9 Aug 2001 10:05:22 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f79H8Xq01162; Thu, 9 Aug 2001 10:08:33 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108091708.f79H8Xq01162@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: tlambert2@mindspring.com Cc: Greg Lehey , void , freebsd-hackers@FreeBSD.org Subject: Re: Allocate a page at interrupt time In-reply-to: Your message of "Thu, 09 Aug 2001 03:13:58 PDT." <3B726266.8026211C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 10:08:32 -0700 From: Mike Smith Sender: owner-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 really can't buy the idea that interrupt threads are a good > idea for anything that can flood your bus or interrupt bandwidth, > or have tiny/non-existant FIFOs, relative to the speeds they are > being pushed; right now that means "might be OK for disks; not OK > for really fast network controllers, not OK for sorta fast network > controllers without a lot of adapter RAM, not OK for serial ports > and floppies", at least in my mind. The basic problem here is that you have decided what "interrupt threads" are, and aren't interested in the fact that what FreeBSD calls "interrupt threads" are not the same thing, despite being told this countless times, and despite it being embodied in the code that's right under your nose. You believe that an interrupt results in a make-runnable event, and at some future time, the interrupt thread services the interrupt request. This is not the case, and never was. The entire point of having interrupt threads is to allow interrupt handling routines to block in the case where the handler/driver design does not allow for nonblocking synchronisation between the top and bottom halves. Most of the issues you raise regarding livelock can be mitigated with thoughtful driver design. Eventually, however, the machine hits the wall, and something has to break. You can't avoid this, no matter how you try; the goal is to put it off as long as possible. So. Now you've been told again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 10:14: 1 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 9FE5937B401; Thu, 9 Aug 2001 10:13:54 -0700 (PDT) (envelope-from jon@enterprise.spock.org) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Thu, 9 Aug 2001 13:13:52 -0400 (EDT) (envelope-from jon)$ Date: Thu, 9 Aug 2001 13:13:52 -0400 From: Jonathan Chen To: bv@wjv.com Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: forwarding broadcast Message-ID: <20010809131352.A15148@enterprise.spock.org> References: <20010809113638.A9519@enterprise.spock.org> <20010809122352.B32613@wjv.com> <20010809123056.G9519@enterprise.spock.org> <20010809125747.A33178@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <20010809125747.A33178@wjv.com>; from bill@wjv.com on Thu, Aug 09, 2001 at 12:57:47PM -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 Thu, Aug 09, 2001 at 12:57:47PM -0400, Bill Vermillion wrote: > On Thu, Aug 09, 2001 at 12:30:56PM -0400, Jonathan Chen thus sprach: > > On Thu, Aug 09, 2001 at 12:23:52PM -0400, Bill Vermillion wrote: > > > On Thu, Aug 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach: > > > > > > > On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses > > > > are not forwarded. For instance, if I have a FreeBSD router with > > > > interfaces 192.168.1.1 and 192.168.2.1, and I send packets from > > > > 192.168.1.2 to 192.168.2.255, the packets are dropped to the > > > > floor. IMO, this is wrong... > > > > But the question now is - what is the netmask on these interfaces.? > > > That will make a difference. > > > These are both class C networks, and their netmask is specified > > accordingly (/24). I'm pretty sure my setup is correct here. > > So they are two separate networks therefore a broadcast for one > should not go the other. > > If on the other hand you netmask was 255.255.252.0 then > 192.168.0.x thru 192.168.3.255 would be part of the same network > and you'd expect a broadcast to propagate. At least this is how I > understand how it works, and I could be wrong. I think you are misundering the setup here. In plain english and without the use of confusing IP/netmasks: A machine connected to interface 0 of the router is sending a unicast ethernet packet (directed to interface 0 of the router) to the ip broadcast address of interface 1. It used to be that routers were expected to go ahead and broadcast the same ip packet on network 1, but a recently updated standard changed the requirements so it is no longer true. Of course, broadcasts from a machine on interface 0 to the ip broadcast address of network 0 is not expected to appear on network 1... -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 10:27:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id 9D85B37B405; Thu, 9 Aug 2001 10:27:06 -0700 (PDT) (envelope-from yushunwa@amc.isi.edu) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f79HR5n42812; Thu, 9 Aug 2001 10:27:06 -0700 (PDT) (envelope-from yushunwa@amc.isi.edu) Date: Thu, 9 Aug 2001 10:27:05 -0700 (PDT) From: Yu-Shun Wang To: Jonathan Chen Cc: , Subject: Re: forwarding broadcast In-Reply-To: <20010809113638.A9519@enterprise.spock.org> Message-ID: <20010809102555.Y42772-100000@amc.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I think it's specified in RFC 2644. It might be useful to site it in the comments of the code. Regards, yushun. ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California On Thu, 9 Aug 2001, Jonathan Chen wrote: > On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not > forwarded. For instance, if I have a FreeBSD router with interfaces > 192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to > 192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... > but I haven't consulted all the RFC's so I'm not sure if some standard out > there calls for it. In any case, the following patch creates a sysctl knob > to turn on or off this feature (since it can be considered a security risk > by some). I just want to ask around in case I turned out to be doing > something incredibly evil. Comments? > > -Jon > > Index: in.h > =================================================================== > RCS file: /export/ncvs/src/sys/netinet/in.h,v > retrieving revision 1.55 > diff -u -r1.55 in.h > --- in.h 2001/06/15 00:37:27 1.55 > +++ in.h 2001/08/09 15:12:19 > @@ -452,7 +452,8 @@ > #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */ > #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */ > #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */ > -#define IPCTL_MAXID 17 > +#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */ > +#define IPCTL_MAXID 18 > > #define IPCTL_NAMES { \ > { 0, 0 }, \ > Index: ip_input.c > =================================================================== > RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v > retrieving revision 1.174 > diff -u -r1.174 ip_input.c > --- ip_input.c 2001/06/23 17:17:58 1.174 > +++ ip_input.c 2001/08/09 15:33:59 > @@ -103,6 +103,10 @@ > SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, > &ipforwarding, 0, "Enable IP forwarding between interfaces"); > > +int ipforward_broadcast = 0; > +SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast, CTLFLAG_RW, > + &ipforward_broadcast, 0, "Enable broadcast packets when forwarding IP packets"); > + > static int ipsendredirects = 1; /* XXX */ > SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, > &ipsendredirects, 0, "Enable sending IP redirects"); > @@ -1684,7 +1688,8 @@ > } > > error = ip_output(m, (struct mbuf *)0, &ipforward_rt, > - IP_FORWARDING, 0); > + IP_FORWARDING| > + (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0); > if (error) > ipstat.ips_cantforward++; > else { > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 11: 3:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from logatome.francenet.fr (logatome-2.francenet.fr [193.149.96.2]) by hub.freebsd.org (Postfix) with ESMTP id C71E337B403 for ; Thu, 9 Aug 2001 11:03:16 -0700 (PDT) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (prov42.dialup.fluxus.net [193.149.102.42]) by logatome.francenet.fr (8.10.1/8.11.1) with ESMTP id f79I3Aj17951 for ; Thu, 9 Aug 2001 20:03:11 +0200 (CEST) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id 79257E6EC1; Thu, 9 Aug 2001 19:50:26 +0200 (CEST) To: Mailing List FreeBSD Hackers Subject: DSL connectivity & ISDN backup From: Eric Masson Message-ID: <86n159qlgb.fsf@notbsdems.nantes.kisoft-services.com> X-Operating-System: FreeBSD 4.4-PRERELEASE i386 Date: Thu, 09 Aug 2001 19:50:24 +0200 Lines: 41 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) 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, Feel Free to redirect if -hackers isn't the most appropriate list. I'll soon get a DSL line for Internet connectivity but as stated in the following papers (Thanks to Ted Mittlestaedt), DSL hasn't been designed as a fully reliable media. http://www.computerbits.com/archive/2001/0200/network0102.html http://www.computerbits.com/archive/2001/0300/middlestaedt0103.html Ted shows a way to add reliability by backing up DSL line via ppp(8) http://www.computerbits.com/archive/2001/0400/mittelstaedt0104.html http://www.computerbits.com/archive/2001/0500/mittelstaedt0501.html The exposed method has one major drawback, the need for the isp to create a special configuration for your use and I don't know if the isp we've chosen will do that. Another one is more specific to France where most of the usual DSL ethernet TAs only support pppoe, thus making ppp(8) mandatory for the DSL connectivity. So you do not have any arp entry for the address the isp assigned to you. How is it possible in this case to detect DSL line failure and then change default route to use the backup ppp(8) dialup configuration ? Any idea ? It would be nice to see this kind of setup handled by ppp(8) via a new keyword like which parameter would be the configuration to use for backup. Thanks in advance Eric Masson --


peut-on acceder avec xterm sous windows à linux en tant qu'utilisateur root, ou avec un utilisateur différent qui a les mêmes droits -+- FML in Guide du linuxien pervers : "Bien configurer son article" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 11:12:42 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 C439237B403 for ; Thu, 9 Aug 2001 11:12:33 -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 LAA29392; Thu, 9 Aug 2001 11:12:26 -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: <20010808222019.92C923A07E@postfix.sekt7.org> Date: Thu, 09 Aug 2001 11:12:28 -0700 (PDT) From: John Baldwin To: Evan Sarmiento Subject: RE: mutex locking pgrp Cc: freebsd-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 08-Aug-01 Evan Sarmiento wrote: > Hello, > > I was looking through kern_proc.c, and I noticed that unlike pfind, > pgfind does not lock the pointer to a structure being returned, > further investigating showed that the definition fo the pgrp > structure itself, in proc.h, doesn't have a mtx struct defined > within it either. > > My proposal is to create a patch that would create pgrp locking, > by adding a mtx to pgrp, and then a MACRO which locks > and unlocks that structure, like PROC_LOCK() > > Would this create any problems? Seigo Tanimura-san is already working on such a patch. tanimura@FreeBSD.org -- 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 Thu Aug 9 11:35:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 459FB37B401 for ; Thu, 9 Aug 2001 11:35:10 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f79IZ6s90603; Thu, 9 Aug 2001 13:35:06 -0500 (CDT) (envelope-from nick@rogness.net) Date: Thu, 9 Aug 2001 13:35:06 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Eric Masson Cc: Mailing List FreeBSD Hackers Subject: Re: DSL connectivity & ISDN backup In-Reply-To: <86n159qlgb.fsf@notbsdems.nantes.kisoft-services.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 Thu, 9 Aug 2001, Eric Masson wrote: Answered on -questions... Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 11:41:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 8A95F37B401; Thu, 9 Aug 2001 11:41:52 -0700 (PDT) Subject: Need reviewers for busdma changes to ethernet driver To: hackers@freebsd.org, current@freebsd.org Date: Thu, 9 Aug 2001 11:41:52 -0700 (PDT) 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: <20010809184152.8A95F37B401@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 Hi folks: Well, after threatening to do it for a long time, I finally sat down and converted one of my ethernet drivers to use the bus_dma API so that I no longer have to do things like call contigmalloc() and/or vtophys() directly. The changes I made are to the driver in -current, and the new code is at: http://www.freebsd.org/~wpaul/SiS/busdma I have tested this driver on FreeBSD/x86 using a NatSemi DP83815 card (the Netgear FA312TX) and it seems to work fine for me. However, I'm not 100% certain I used the busdma API properly in all cases. If anyone with a busdma clue would care to look over the code and see everything looks more or less legal, I would appreciate it. My main concern is that I'm using bus_dma_load() and bus_dma_unload() correctly (i.e. such that I'm not leaking any resources). Unless anyone raises serious objections, I would like to commit this code ASAP (the last test I really need to do is make sure it works correctly on an alpha). -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 Thu Aug 9 13:15:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from postfix.sekt7.org (209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com [209.6.248.16]) by hub.freebsd.org (Postfix) with ESMTP id 98E9C37B407; Thu, 9 Aug 2001 13:15:07 -0700 (PDT) (envelope-from ems@open-root.org) Received: from smtp.sekt7.org (postfix.sekt7.org [169.69.6.38]) by postfix.sekt7.org (Postfix) with SMTP id 53D283A07E; Thu, 9 Aug 2001 16:15:05 -0400 (EDT) From: Evan Sarmiento To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: kernel hooks Message-Id: <20010809201505.53D283A07E@postfix.sekt7.org> Date: Thu, 9 Aug 2001 16:15:05 -0400 (EDT) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hey, Like was said in the status report, I am working on the security hooks, I released a preliminary patch about a week ago, put it into GNATS. No one has reviewed it yet, I was wondering if someone would be willing to take a look? http://www.freebsd.org/cgi/query-pr.cgi?pr=29423 I am also writing a paper on it, I'll probably post my first draft, if anyone wants to see it. So you can get a better idea of what I'm doing. If you're not up on this, here is a brief description of what I'm doing: Kernel Security Hooks provide a standard interface for programmers of kernel security extensions to intercept system calls and other functions. Before, programmers had to wrap the system call with their own system call, resulting in two copyins. PRFW, the kernel security hook patch I am addressing in this PR, provides a standard interface for these uses. It also provides per-pid restrictions, so process X might not be able to use setuid but process Y might, depending on what restrictions you write. Thanks a lot, -- ----------------------------------- Evan Sarmiento | www.open-root.org ems@sekt7.org | www.sekt7.org/~ems/ ----------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 16:10:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from yonge.cs.toronto.edu (yonge.cs.toronto.edu [128.100.1.8]) by hub.freebsd.org (Postfix) with SMTP id 318B837B401; Thu, 9 Aug 2001 16:10:33 -0700 (PDT) (envelope-from khui@cs.toronto.edu) Received: from jane.cs.toronto.edu ([128.100.2.31]) by yonge.cs.toronto.edu with SMTP id <33963-21682>; Thu, 9 Aug 2001 19:10:28 -0400 Received: from gardiner.cs.toronto.edu by jane.cs.toronto.edu id <453140-21860>; Thu, 9 Aug 2001 19:10:18 -0400 Date: Thu, 9 Aug 2001 19:10:06 -0400 From: Kevin Hui X-Sender: khui@gardiner.cs To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Experiencing very slow raw write speeds on /dev/ad1 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 Hi all, I have installed 2 Maxtor UDMA100 drives in my system, sharing the channel ide0. /dev/ad0 contains all the FreeBSD partitions and ad1 is used as a scratch drive (there's nothing on it). Ide1 channel is used for the DVD drive (which doesn't support UDMA): ad0: 39083MB [79408/16/63] at ata0-master UDMA100 ad1: 39083MB [79408/16/63] at ata0-slave UDMA100 acd0: DVD-ROM at ata1-master using PIO4 Running rawio (available from the Ports collection under benchmarks) on /dev/ad1 shows the following: # rawio -p 1 -r /dev/ad1 Random read Sequential read Random write Sequential write ID K/sec /sec K/sec /sec K/sec /sec K/sec /sec ad1 36175.1 2208 # rawio -p 1 -w /dev/ad1 Random read Sequential read Random write Sequential write ID K/sec /sec K/sec /sec K/sec /sec K/sec /sec ad1 950.1 58 The single-process sequential read time is very good (~36MB/s) but the single-process sequential write time is terrible (950.1KB/s). Does anyone have any idea why this is happening? How complete is the support for UDMA under FreeBSD? I'm using the VIA 82C686 onboard ATA100 controller. Any information would be appreciated. -Kevin. ----------------------- FreeBSD 4.3-RELEASE #0: Sat Apr 21 10:54:49 GMT 2001 jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1004.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 268353536 (262064K bytes) avail memory = 256905216 (250884K bytes) ... atapci0: port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 16:21:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by hub.freebsd.org (Postfix) with ESMTP id 6724537B403 for ; Thu, 9 Aug 2001 16:21:35 -0700 (PDT) (envelope-from archer@whichever.org) Received: from 207-172-201-171.s44.as3.xnb.nj.dialup.rcn.com ([207.172.201.171] helo=unknown.whichever.org) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.32 #2) id 15Uz7N-00052G-00 ; Thu, 09 Aug 2001 19:21:34 -0400 Received: (from archer@localhost) by unknown.whichever.org (8.11.5/8.11.1) id f79NKnA04067; Thu, 9 Aug 2001 19:20:49 -0400 (EDT) (envelope-from archer) Date: Thu, 9 Aug 2001 19:20:49 -0400 (EDT) Message-Id: <200108092320.f79NKnA04067@unknown.whichever.org> From: Alexander Litvin To: Alfred Perlstein Cc: hackers@freebsd.org Subject: Re: gethostbyXXXX_r() In-Reply-To: <20010803131115.F85642@elvis.mu.org> X-Newsgroups: unknown.freebsd.hackers User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-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 <20010803131115.F85642@elvis.mu.org> you wrote: > Please complete it, let me know when you submit the PR i'll try > to get it integrated. Ok, I submitted it: http://www.freebsd.org/cgi/query-pr.cgi?pr=29581 I tried to make as few changes as possible, but still diff is quite big IMHO. And changed only dns and files. I didn't do anything about nis -- mostly because I have no place to test it right now. Should be pretty simple to modify nis code too. -- #include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 17:14:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 5108837B401 for ; Thu, 9 Aug 2001 17:14:12 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 53C4F6ACD2; Fri, 10 Aug 2001 09:44:31 +0930 (CST) Date: Fri, 10 Aug 2001 09:44:31 +0930 From: Greg Lehey To: smail Cc: freebsd-hackers@FreeBSD.org Subject: mmap limits (was: need help) Message-ID: <20010810094431.X73579@wantadilla.lemis.com> References: <15541463687.20010801001742@estart.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15541463687.20010801001742@estart.ru>; from smail@eStart.ru on Wed, Aug 01, 2001 at 12:17:42AM +0700 Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-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 Wednesday, 1 August 2001 at 0:17:42 +0700, smail wrote: > Hello freebsd-hackers, > > i need some help. my problem is about memory limit in mmap function. > i can't mmap files infinitely, after some number of file mmaped in > memory i've got an error, probably causing memory limit of 2 or 4 Gb. > can you help me? my platform is FreeBSD 4.3/i386 [128Mb RAM, 4Gb > swap]. You'll get more replies with an appropriate subject and some more details. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 17:41: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 2B33B37B401; Thu, 9 Aug 2001 17:41: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 f7A0fPl11990; Thu, 9 Aug 2001 18:41: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 f7A0fP132516; Thu, 9 Aug 2001 18:41:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108100041.f7A0fP132516@harmony.village.org> To: Yu-Shun Wang Subject: Re: forwarding broadcast Cc: Jonathan Chen , net@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Aug 2001 10:27:05 PDT." <20010809102555.Y42772-100000@amc.isi.edu> References: <20010809102555.Y42772-100000@amc.isi.edu> Date: Thu, 09 Aug 2001 18:41: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 <20010809102555.Y42772-100000@amc.isi.edu> Yu-Shun Wang writes: : I think it's specified in RFC 2644. It might be useful : to site it in the comments of the code. There were several incidents in the early days of the internet when this functionality was in place that caused all kinds of problems. Look at the trouble that Jordan got into in 1983 (search the RISKS archives) when he send a broadcast to all (which sent the wall to the entire internet at the time). While this wasn't exactly a network level broadcast, consider carefully the ramifications. There are many cases where could be useful turns into a security nightmare, so I'd be extremely reluctant to include this patch... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 20:52: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id C383937B401; Thu, 9 Aug 2001 20:52:03 -0700 (PDT) (envelope-from yushunwa@amc.isi.edu) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f7A3puB43644; Thu, 9 Aug 2001 20:51:56 -0700 (PDT) (envelope-from yushunwa@amc.isi.edu) Date: Thu, 9 Aug 2001 20:51:56 -0700 (PDT) From: Yu-Shun Wang To: Warner Losh Cc: Jonathan Chen , , Subject: Re: forwarding broadcast In-Reply-To: <200108100041.f7A0fP132516@harmony.village.org> Message-ID: <20010809204505.Q43632-100000@amc.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Sorry for not making it clear. I believe RFC 2644 actually suggested that routers MUST default to disabling directed broadcast except explicitly configured to do so. But I guess one can never be too careful. :-) yushun. ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California On Thu, 9 Aug 2001, Warner Losh wrote: > In message <20010809102555.Y42772-100000@amc.isi.edu> Yu-Shun Wang writes: > : I think it's specified in RFC 2644. It might be useful > : to site it in the comments of the code. > > There were several incidents in the early days of the internet when > this functionality was in place that caused all kinds of problems. > Look at the trouble that Jordan got into in 1983 (search the RISKS > archives) when he send a broadcast to all (which sent the wall to the > entire internet at the time). While this wasn't exactly a network > level broadcast, consider carefully the ramifications. > > There are many cases where could be useful turns into a security > nightmare, so I'd be extremely reluctant to include this patch... > > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 21:18:38 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 54AD137B401; Thu, 9 Aug 2001 21:18:27 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA83750; Thu, 9 Aug 2001 21:10:01 -0700 (PDT) Message-ID: <3B735D2D.AAA08977@elischer.org> Date: Thu, 09 Aug 2001 21:03:57 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Robert Watson Cc: developers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: FreeBSD Status Report, July 2001 References: Content-Type: text/plain; charset=iso-8859-2 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 Robert Watson wrote: > now out of date... 1.2MB pattches GENERIC compiles boots to almost single user without the scheduler changes.. (they happen later).. > Project: KSE threading the kernel > URL: http://people.freebsd.org/~jasone/kse/ > Contact: julian@elischer.org > > I'm working on multithreading the kernel. So far I have over 400KB of > diffs relative to todays -current (I'm keeping my tree updated with > changes as they occur rather than get hit with a big update at the end). > > I have split the proc structure and am changing most of the kernel to > pass around a thread identifier instead of a proc structure. > > The following interfaces have been changed so far: > device devsw entries > vfs calls > mutexes > events > system calls > scheduler > + a lot of code in between. > > I have still a lot of work to go with a lot of "dumb editing" (s/struct > proc \*p/struct thread \*td/) usually I change a few items and then fix > everything that breaks when I try compile it. I'd like to check it in > on a branch so others can help the editing but haven't worked out the > best way to do it yet. > > I have implemented changes to the scheduler so that kse's are scheduled > instead of processes, and threads sleep, letting the kse pick up a new > thread. but it's not anywhere ready yet (heck it doesn't compile yet > :-) > > Note that I have not yet updated the document listed above.. everywhere > it mentions "ksec" or "KSE-context", the code uses the word "thread". I > will update it soon as Jason has sent me the DOcs updated in this regard but still need more work... > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 21:58:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.6test.edu.cn (ns.6test.edu.cn [202.112.54.2]) by hub.freebsd.org (Postfix) with ESMTP id 94A5137B401 for ; Thu, 9 Aug 2001 21:58:29 -0700 (PDT) (envelope-from huxw@ns.6test.edu.cn) Received: (from huxw@localhost) by ns.6test.edu.cn (8.9.2+3.1W/8.9.2) id MAA26935 for hackers@freebsd.org; Fri, 10 Aug 2001 12:53:57 +0800 (CST) From: Xinwei Hu Message-Id: <200108100453.MAA26935@ns.6test.edu.cn> Subject: How to increase the routing table size? To: hackers@freebsd.org Date: Fri, 10 Aug 2001 12:53:57 +0800 (CST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] 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 Hi all: I'm using freebsd 4.4 and discovered that it is limited to contain 74447 host routing entries. But what should I do to increase the routing table for more entries? I've tried to increase the size of kernel space, but not effected. Thanks for your advices. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 9 23:17:42 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 7633537B403 for ; Thu, 9 Aug 2001 23:17:39 -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 f7A6HZV06808 for ; Fri, 10 Aug 2001 08:17:36 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: hackers@freebsd.org Subject: Ghostscript 6.51 + HP printer = WOW! From: Poul-Henning Kamp Date: Fri, 10 Aug 2001 08:17:35 +0200 Message-ID: <6806.997424255@critter> Sender: owner-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 new ghostscript 6.51 has integrated the HPIJS backends for HP printers. HPIJS is written by HP and contains most of their weird colormunging technologies. I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I can only say "WOW!". I beats the pants of all the other HP/PCL/whatever backends in ghostscript. Highly recommended! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 1:27:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.agava.net.ru (2.oivt.mipt.ru [193.125.142.2]) by hub.freebsd.org (Postfix) with ESMTP id EA8AD37B406; Fri, 10 Aug 2001 01:27:21 -0700 (PDT) (envelope-from frank@agava.com) Received: from gw.office.agava.ru (2.oivt.mipt.ru [193.125.142.2]) by relay2.agava.net.ru (Postfix) with ESMTP id 195A94387B; Fri, 10 Aug 2001 12:27:19 +0400 (MSD) Received: from hellbell.domain (hellbell.domain [192.168.1.12]) by gw.office.agava.ru (Postfix) with ESMTP id B9DCE6173; Fri, 10 Aug 2001 12:27:14 +0400 (MSD) Received: from localhost (localhost [127.0.0.1]) by hellbell.domain (Postfix) with ESMTP id 6D53ECCF2; Fri, 10 Aug 2001 12:27:14 +0400 (MSD) Date: Fri, 10 Aug 2001 12:27:14 +0400 (MSD) From: Alexey Zakirov X-X-Sender: To: Greg Lehey Cc: smail , Subject: Re: mmap limits (was: need help) In-Reply-To: <20010810094431.X73579@wantadilla.lemis.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 Fri, 10 Aug 2001, Greg Lehey wrote: > > i can't mmap files infinitely, after some number of file mmaped in > > memory i've got an error, probably causing memory limit of 2 or 4 Gb. > > can you help me? my platform is FreeBSD 4.3/i386 [128Mb RAM, 4Gb > > swap]. > > You'll get more replies with an appropriate subject and some more > details. probably he says about http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18209. *** WBR, Alexey Zakirov (frank@agava.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 1:50:40 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 B1E7737B401; Fri, 10 Aug 2001 01:50:34 -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 SAA13822; Fri, 10 Aug 2001 18:20:32 +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: <6806.997424255@critter> Date: Fri, 10 Aug 2001 18:20:32 +0930 (CST) From: "Daniel O'Connor" To: Poul-Henning Kamp Subject: RE: Ghostscript 6.51 + HP printer = WOW! 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 10-Aug-2001 Poul-Henning Kamp wrote: > The new ghostscript 6.51 has integrated the HPIJS backends for HP printers. > > HPIJS is written by HP and contains most of their weird colormunging > technologies. > > I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I > can > only say "WOW!". I beats the pants of all the other HP/PCL/whatever > backends > in ghostscript. > > Highly recommended! The Epson 880 etc drivers made by the Gimp folks are pretty damn nice too. Photo printing takes a long time (like 20-30 minutes :) but looks _amazing_ --- 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 Fri Aug 10 1:59: 8 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 C821C37B403 for ; Fri, 10 Aug 2001 01:59:03 -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 f7A8wnV09446; Fri, 10 Aug 2001 10:58:49 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Daniel O'Connor" Cc: hackers@freebsd.org Subject: Re: Ghostscript 6.51 + HP printer = WOW! In-Reply-To: Your message of "Fri, 10 Aug 2001 18:20:32 +0930." Date: Fri, 10 Aug 2001 10:58:49 +0200 Message-ID: <9444.997433929@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 , "Daniel O'Connor" writes: > >On 10-Aug-2001 Poul-Henning Kamp wrote: >> The new ghostscript 6.51 has integrated the HPIJS backends for HP printers. >> >> HPIJS is written by HP and contains most of their weird colormunging >> technologies. >> >> I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I >> can >> only say "WOW!". I beats the pants of all the other HP/PCL/whatever >> backends >> in ghostscript. >> >> Highly recommended! > >The Epson 880 etc drivers made by the Gimp folks are pretty damn nice too. Yeah, but until now you have not been able to use the PhotoRet stuff in the the HP's at all unless you ran winblows. >Photo printing takes a long time (like 20-30 minutes :) but looks _amazing_ Depends a lot on your connection/printer of course. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 2:53:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id B127637B403 for ; Fri, 10 Aug 2001 02:53:06 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.105.137.Dial1.SanJose1.Level3.net [209.244.105.137]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA11348; Fri, 10 Aug 2001 02:52:58 -0700 (PDT) Message-ID: <3B73AF23.43CC6C05@mindspring.com> Date: Fri, 10 Aug 2001 02:53:39 -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: smail Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: need help References: <15541463687.20010801001742@estart.ru> 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 smail wrote: > > Hello freebsd-hackers, > > i need some help. my problem is about memory limit in mmap function. > i can't mmap files infinitely, after some number of file mmaped in > memory i've got an error, probably causing memory limit of 2 or 4 Gb. > can you help me? my platform is FreeBSD 4.3/i386 [128Mb RAM, 4Gb > swap]. This is probably your homework, isn't it? 8-) Your address space is by default limited to 3G (the kernel virtual address space is 1G and the user address space is 3G: the kernel needs to be able to get at all memory. You can change this a little, but you will still bump your head on the limiting fact that you have only 32 bits with which to address all the memory you use. To exceed this limit, you will have to go to indirect mappings; using indirect mappings, you divide your address space up into chunks, and then when you need to access an additional chunk of data, and all your chuncks are busy, you evict a previous mapping and map the chunk there instead. A common algorithm for this type of eviction is LRU. Effectively, you are managing the mapping to implement in software a virtual address space in excess of your 3G limit; in effect, there is no practical limit on the amount of data you can access in this way, since you could go to eviction of your table of ranges, after going to a hierarchy of tables of ranges of file data that you map. A simple example of this technique would be to map a smaller portion of the file (say 8MB of the file) at a time, and keep a quad word (C type "long long", FreeBSD type "off_t") of the offset. To access the first 8MB of the file, mmap it in memory, and iterate through it. Now iterate through 8GB of the file by moving the mapping, only when necessary. This technique is known as "windowing"; here is a simple example, which won't compile without header files, probably needs "LL" constant identifiers to make them 64 bits, and may have a typo even after you add the header files; it will also be incredibly slow, since the algorithm parameters should be tuned to the data you will be accessing: /* I call this program "How much is that file in the window?"*/ void *basep; /* window address*/ off_t relbase; /* window base*/ off_t eight_meg = 0x000000000080000; /* window size*/ int memfd; /* lazy global*/ /* * Stupid program to dump out the first 8G of a file, one * byte at a time, using a windowed "get byte" function. */ main() { off_t curoff; unsigned char c; memfd = open( "my_overly_large_file", O_RDONLY, 0); /* Go from 0 to 8G, one byte at a time...*/ for( curoff = 0; curoff < 0x0000000100000000; curoff++) { c = byte_at_offset( curoff); putchar(c); } } /* * Access a character in an arbitrary length file by mapping * it into memory in 8M windows, changing the mapping when * the requested character lands before or after the current * window, so that a lot of mapping and unmapping isn't needed. */ unsigned char byte_at_offset(off_t offset) { off_t reloffset = offset - relbase; /* * if the offset is before, or after the window, or * if we haven't yet set up a window, then we need to * modify the window we are using. */ if( relbase > offset || reloffset > eight_meg || basep == NULL) { /* if this is the first time, there is nothing to unmap*/ if( basep != NULL) { munmap( basep, eight_meg); } /* get a new relative base, offset, and a new window*/ relbase = offset - (offset % eight_meg); reloffset = offest - relbase; basep = mmap( NULL, eight_meg, PROT_READ, MAP_SHARED, memfd, relbase; } /* * return the requested character from its relative * location in the window. */ return *(unsigned char *)&basep[ reloffset]; } -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 3:13:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 3A86F37B405; Fri, 10 Aug 2001 03:13:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.105.137.Dial1.SanJose1.Level3.net [209.244.105.137]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id DAA00327; Fri, 10 Aug 2001 03:13:11 -0700 (PDT) Message-ID: <3B73B3DF.EC098517@mindspring.com> Date: Fri, 10 Aug 2001 03:13:51 -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: Mike Smith Cc: Greg Lehey , void , freebsd-hackers@freebsd.org Subject: Re: Allocate a page at interrupt time References: <200108091708.f79H8Xq01162@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > The basic problem here is that you have decided what "interrupt threads" > are, and aren't interested in the fact that what FreeBSD calls "interrupt > threads" are not the same thing, despite being told this countless times, > and despite it being embodied in the code that's right under your nose. > > You believe that an interrupt results in a make-runnable event, and at > some future time, the interrupt thread services the interrupt request. > > This is not the case, and never was. The entire point of having > interrupt threads is to allow interrupt handling routines to block in the > case where the handler/driver design does not allow for nonblocking > synchronisation between the top and bottom halves. So enlighten me, since the code right under my nose often does not run on my dual CPU system, and I like prose anyway, preferrably backed by data and repeatable research results. What do interrupt threads buy you that isn't there in 4.x, besides being one hammer among dozens that can hit the SMP nail? Why don't I want to run my interrupt to completion, and want to use an interrupt thread to do the work instead? On what context do they block? Why is it not better to change the handler/driver design to allow for nonblocking synchronization? Personally, when I get an ACK from a SYN/ACK I sent in response to a SYN, and the connection completes, I think that running the stack at interrupt all the way up to the point of putting the completed new socket connection on the associated listening socket's accept list is the correct thing to do; likewise anything else that would result in a need for upper level processing, _at all_. This lets me process everything I can, and drop everything I can't, as early as possible, before I've invested a lot of futile effort in processing that will come to naught. This is what LRP does. This is what Van Jacobson's stack (van@packetdesign.com) does. Why are you right, and Mohit Aron, Jeff Mogul, Peter Druschel, and Van Jacobson, wrong? > Most of the issues you raise regarding livelock can be > mitigated with thoughtful driver design. Eventually, > however, the machine hits the wall, and something has to > break. You can't avoid this, no matter how you try; the > goal is to put it off as long as possible. > > So. Now you've been told again. Tell me why it has to break, instead of me disabling receipt of the packets by the card in order to shed load before it becomes an issue for the host machine's bus, interrupt processing system, etc.? Are you claiming that dropping packets that are physically impossible to handle, as early as possible, while handing _all_ packets that are physically possible to handle, is "broken", or is somehow "unpossible"? Thanks for any light you can shed on the subject, -- Terry PS: If you want to visit me at work, I'll show you code running in a significantly modified FreeBSD 4.3 kernel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 3:58:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id C841D37B401 for ; Fri, 10 Aug 2001 03:58:39 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.5/8.11.4) id f7AAwWY10291; Fri, 10 Aug 2001 14:58:32 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108101058.f7AAwWY10291@bugz.infotecs.ru> Subject: Re: SMBFS and NETSMB? To: sheldonh@starjuice.net (Sheldon Hearn) Date: Fri, 10 Aug 2001 14:58:32 +0400 (MSD) Cc: freebsd-hackers@freebsd.org In-Reply-To: <24279.997437082@axl.seasidesoftware.co.za> from "Sheldon Hearn" at Aug 10, 2001 11:51:22 AM 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 > You can try the following in your kernel config: > > options NETSMB > options NETSMBCRYPTO > options LIBMCHAIN > options ICONV I think it's "options LIBICONV" (or do both work ?). Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 4: 8:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 00D4C37B401 for ; Fri, 10 Aug 2001 04:08:33 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15VAAZ-0006oi-00; Fri, 10 Aug 2001 13:09:35 +0200 From: Sheldon Hearn To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: SMBFS and NETSMB? In-reply-to: Your message of "Fri, 10 Aug 2001 14:58:32 +0400." <200108101058.f7AAwWY10291@bugz.infotecs.ru> Date: Fri, 10 Aug 2001 13:09:35 +0200 Message-ID: <26207.997441775@axl.seasidesoftware.co.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 10 Aug 2001 14:58:32 +0400, "Eugene L. Vorokov" wrote: > > options NETSMB > > options NETSMBCRYPTO > > options LIBMCHAIN > > options ICONV > > I think it's "options LIBICONV" (or do both work ?). No, you're right. I'ts LIBICONV. Sorry. I use the modules, since I don't like to wait for the panics. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 5: 6:29 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 32D4337B401 for ; Fri, 10 Aug 2001 05:06:20 -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 GHUPMN00.2EV for ; Fri, 10 Aug 2001 14:06:23 +0200 Message-ID: <003101c12195$3be399a0$0201a8c0@teledisnet.be> From: "Sansonetti Laurent" To: Subject: Doing file operations on syscalls handler Date: Fri, 10 Aug 2001 14:08:57 +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 Hello hackers, I'm new on FreeBSD modules programming, and I've a little question... How can I do file operations (like open(), read()..) on a syscall handler of a syscall module ? In fact I've met the problem since my module must open a file which contains some informations for the hacked syscall (in this case, it's getdirentries()).. I've tried to malloc a open_args struct, filled-it and use [sys] open, but it doesn't work... Is there a way to call user syscalls ? Thanks you for your answer.. I don't have many informations on FreeBSD modules programming.. forgive-me ;) -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 5:46:54 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 BA18437B401 for ; Fri, 10 Aug 2001 05:46:50 -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 WAA16382; Fri, 10 Aug 2001 22:16:25 +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: <9444.997433929@critter> Date: Fri, 10 Aug 2001 22:16:26 +0930 (CST) From: "Daniel O'Connor" To: Poul-Henning Kamp Subject: Re: Ghostscript 6.51 + HP printer = WOW! 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 10-Aug-2001 Poul-Henning Kamp wrote: > >The Epson 880 etc drivers made by the Gimp folks are pretty damn nice too. > > Yeah, but until now you have not been able to use the PhotoRet stuff in the > the HP's at all unless you ran winblows. I lach a modern HP for comparisson I guess :) > >Photo printing takes a long time (like 20-30 minutes :) but looks _amazing_ > Depends a lot on your connection/printer of course. Hmm this was USB which I would assume was the faster method. (Assumption...) --- 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 Fri Aug 10 6:20:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id BE62237B406 for ; Fri, 10 Aug 2001 06:20:27 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from root@localhost) by bugz.infotecs.ru (8.11.5/8.11.4) id f7ADKEq11115; Fri, 10 Aug 2001 17:20:14 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108101320.f7ADKEq11115@bugz.infotecs.ru> Subject: Re: Doing file operations on syscalls handler To: lorenzo@linuxbe.org (Sansonetti Laurent) Date: Fri, 10 Aug 2001 17:20:14 +0400 (MSD) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Sansonetti Laurent" at Aug 10, 2001 02:08:57 PM 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 > Hello hackers, > > I'm new on FreeBSD modules programming, and I've a little question... > How can I do file operations (like open(), read()..) on a syscall handler of > a syscall module ? > In fact I've met the problem since my module must open a file which contains > some informations for the hacked syscall (in this case, it's > getdirentries()).. > I've tried to malloc a open_args struct, filled-it and use [sys] open, but > it doesn't work... > Is there a way to call user syscalls ? > > Thanks you for your answer.. I don't have many informations on FreeBSD > modules programming.. forgive-me ;) I think I should put this onto some webpage or something, as I had to post this several times already :). Guys, please please please search mailing list archives prior to asking. In most cases, when you "need" to read files from kernel modules, it means that you should rethink your problem and the way you go to solve it. I don't have much information about what you're trying to do, but according to what you say, you can pretty well have some userland program which will read the file and pass the information to your module (for instance, your module can create a device and your userland program can open() it and write() to it, or you can add new syscall, or whatever). This is how for instance ipfw and ipf work, modules theirselves don't read configuration files. Think about speed, too: imagine your system getting numerous getdirentries() syscalls in a short time - reading from the file each time would slow down your system a lot. However, there are some cases when you still need to read from a file from your module. For istance, I have a module which must read it's config file on startup itself, because it contains information about which programs are allowed to use it's device i/o interface later. In most circumstances it can be done, however I think it will not work when you are in the interrupt handler or other state where disk i/o isn't surely possible. If you intercept getdirentries(), I think it will pretty well work, but I can only say that my method works for me in MOD_LOAD event handler. Basicly, the problem is that all syscalls expect their arguments to be pointers to the userland memory and not kernel. As you probably know, these are totally separated. All syscalls use copyin() to copy arguments from userland, and this function makes sure that argument is located in userland, and returns error if it isn't. This is done like that to avoid userland programs passing kernel addresses to syscalls and thus manipulating kernel structures in a manner they never should. Thus, if you want to use syscalls from kernel, you must put arguments in the userland memory of current process and then pass them to the syscall handler. The least dangerous method of getting some piece of userland memory (as seems to me) is using mmap() (or, preferably, vm_mmap() directly) with fd == -1 and MAP_ANON flag. mmap() doesn't require anything to be in userland, you can build your own mmap_args as needed and call mmap(), passing curproc as the first argument. Don't forget that mmap() will only return error code; actuall address of memory allocated, if call was successful, is in the curproc->p_retval[0], which you should rather save before you do syscall and restore later. Once you have buffer allocated, you can copyout() your filename to it and pass that address to open() syscall, then allocate another buffer the same way, call read() on it, then use copyin() to transfer the buffer to kernel space. Do note that you must never use memory allocated by mmap() in the regular manner (C operations, string functions, etc); it may work, and will most probably work currently on i386 machines; but don't be fooled as I was at first, it's not supposed to work, because in general case kernelspace and userspace can have totally different address spaces, and access from one to another would require context switching. You can only use copyin(), copyout(), fubyte(), subyte() and other functions from that family; read manual pages. Of course, don't forget to call close() and munmap() once you're done. Do not try using processes other than curproc for mmap() allocation - it will not work. Avoid defining buffers in kernel as local variables of some functions - kernel stack is very small, and you will most likely end up with a double fault panic; use MALLOC() instead. And, as I always did before, I'll add that all this technology looks like a very ugly hack for me, it's really not a good example of what kernel module should do. Still it works for me. Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 6:26:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by hub.freebsd.org (Postfix) with ESMTP id 8751837B406 for ; Fri, 10 Aug 2001 06:26:19 -0700 (PDT) (envelope-from sumanth.vidyadhara@wipro.com) Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [192.168.235.4]) by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f7AJ5OJ09153 for ; Fri, 10 Aug 2001 19:05:25 GMT Received: from sumanth ([192.168.205.201]) by platinum.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHUTA800.N6M for ; Fri, 10 Aug 2001 18:55:20 +0530 Message-ID: <01a401c121a1$57af1db0$c9cda8c0@sumanth> From: "sumanth vidyadhara" To: Subject: How to read tunables for Network driver at run time in freebsd 4.3 Date: Fri, 10 Aug 2001 19:05:38 +0530 Organization: Wipro Global R&D MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A1_01C121CF.71474E90" ------=_NextPart_000_01A1_01C121CF.71474E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, we are writing a nic driver for ethernet card in freebsd 4.3. I have a doubt on how do we get the configuration parameters like = setting the transmit descriptors,receive decriptors,also some driver = specific tunables at load time of the driver module. Is there any call where the driver module can read that and populate the = variables in the driver(like Space.c in sco or unixware). Any help is greatly appreciated. Thanks, Sumanth ------=_NextPart_000_01A1_01C121CF.71474E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,
  we are writing a nic driver = for =20 ethernet card in freebsd 4.3.
I have a doubt on how do we  get = the=20 configuration parameters like setting the transmit descriptors,receive=20 decriptors,also some driver specific tunables at load time of the driver = module.
 
Is there any call where the driver = module can read=20 that and populate the variables
in the driver(like Space.c in sco or=20 unixware).
 
 
Any help is greatly = appreciated.
 
Thanks,
Sumanth
 
------=_NextPart_000_01A1_01C121CF.71474E90-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" ---------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ---------------------------------------------------------------------------------------------------------------------- --------------InterScan_NT_MIME_Boundary-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 7:10:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f228.pav2.hotmail.com [64.4.37.228]) by hub.freebsd.org (Postfix) with ESMTP id 0FAD037B401 for ; Fri, 10 Aug 2001 07:10:27 -0700 (PDT) (envelope-from sigmafour@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 Aug 2001 07:10:26 -0700 Received: from 66.67.45.30 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 10 Aug 2001 14:10:26 GMT X-Originating-IP: [66.67.45.30] From: "Derek True" To: freebsd-hackers@freebsd.org Subject: Setting ti to half duplex Date: Fri, 10 Aug 2001 10:10:26 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Aug 2001 14:10:26.0671 (UTC) FILETIME=[342C97F0:01C121A6] Sender: owner-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 posted this to freebsd-net but have a feeling I might have posted to the wrong list. Hopefully someone here will know the resolution to the following problem: I'm currently trying to set my 3com 3C985-SX gigabit NIC to Half-Duplex.I've recompiled FreeBSD to include the ti driver but have been unsuccessful in setting it to Half-Duplex. I'm currently getting info from a fiber tap which only sends and cannot recieve. When the NIC enters full-duplex mode the software I'm using on the box shuts down due to the lack of establishing link. This can be resolved by setting the NIC to operate in half-duplex. The ti man page says see ifconfig. Ifconfig says its a driver setting, (so go see the ti man page.) Rc.conf also has been no help. Has anyone here dealt with the same problem? Any help is immensely appreciated. Thanks Tom _________________________________________________________________ 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 Fri Aug 10 7:25:59 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 13FDD37B409 for ; Fri, 10 Aug 2001 07:25:53 -0700 (PDT) (envelope-from jkf@aura.research.bell-labs.com) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Aug 10 10:25:12 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Fri Aug 10 10:25:34 EDT 2001 Received: (from jkf@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id KAA07530; Fri, 10 Aug 2001 10:25:03 -0400 (EDT) Date: Fri, 10 Aug 2001 10:25:03 -0400 (EDT) From: Jeff Fellin Message-Id: <200108101425.KAA07530@aura.research.bell-labs.com> To: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: boot problems Sender: owner-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 cvsup'ed on 8/9 and did a buildworld, installworld, buildkernel, and installkernel. I had last cvsup'ed on 7/15 and the system worked fine. Now when I boot the new kernel from GENERIC, the system doesn't boot. The boot loader loads /boot/kernel/kernel, and when I set boot_verbose, and boot_ddb then boot the new kernel nothing happens. I don't even get the ddb breakpoint. I haven't seen anything in UPDATING mentioning a problem. I'm not sure, but don't believe the pxeboot problem is not an issue here. Can anyone help me with how to resolve the problem? This is also posted on hackers. Thank you Jeff Fellin Room 2A-352 Bell Labs Murray Hill, NJ (908) 582-7673 fellin@lucent.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 7:33:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail38.sdc1.sfba.home.com (femail38.sdc1.sfba.home.com [24.254.60.32]) by hub.freebsd.org (Postfix) with ESMTP id 01B3C37B406 for ; Fri, 10 Aug 2001 07:33:33 -0700 (PDT) (envelope-from europax@home.com) Received: from home.com ([24.12.186.185]) by femail38.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010810143332.JQOO2892.femail38.sdc1.sfba.home.com@home.com> for ; Fri, 10 Aug 2001 07:33:32 -0700 Message-ID: <3B73F0BC.548D40B3@home.com> Date: Fri, 10 Aug 2001 07:33:32 -0700 From: Rob X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: the =+ operator 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 My first post on hackers, so please don't flame me too bad :) I think that only an old hacker can give me the answer :) I've searched far and wide on search engines to find out what the =+ operator does, to no avail. I'm porting some old code and found it. I made a test program and compiled it with gcc, and all it appears to do is the same as regular assignment. But I'm wondering if in some day long ago, it mean't something else? Thanks, Rob. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 7:46:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from safety.net (ns3.safety.net [216.200.162.38]) by hub.freebsd.org (Postfix) with ESMTP id 8A8AC37B401 for ; Fri, 10 Aug 2001 07:46:18 -0700 (PDT) (envelope-from les@safety.net) Received: (from les@localhost) by safety.net (8.9.3/8.9.3) id HAA99867; Fri, 10 Aug 2001 07:46:17 -0700 (MST) (envelope-from les) From: Les Biffle Message-Id: <200108101446.HAA99867@safety.net> Subject: Re: the =+ operator In-Reply-To: <3B73F0BC.548D40B3@home.com> from Rob at "Aug 10, 2001 07:33:32 am" To: europax@home.com (Rob) Date: Fri, 10 Aug 2001 07:46:16 -0700 (MST) Cc: hackers@FreeBSD.ORG (hackers@FreeBSD.ORG) Reply-To: les@safety.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > My first post on hackers, so please don't flame me too bad :) I think > that only an old hacker can give me the answer :) > > I've searched far and wide on search engines to find out what the =+ > operator does, to no avail. I'm porting some old code and found it. I ran into this a couple of times, and it was always a typo by the programmer. Whether they meant to use "+=" or not wasn't always clear. In C, you should imagine reading the code with all of the non-quoted white space removed to see how the compiler will treat something, so "a =+ 1;" is the same as "a=+1;" or "a = +1;" There has never been an operator =+, even checking back to the BCPL days. So, read the code carefully to see if you can figure out if they meant += Regards, -Les -- Les Biffle Community Service... Just Say NO! (480) 585-4099 les@safety.net http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 7:47:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with SMTP id 5938237B406 for ; Fri, 10 Aug 2001 07:47:25 -0700 (PDT) (envelope-from jkf@zydeco.research.bell-labs.com) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Fri Aug 10 10:42:15 EDT 2001 Received: from zydeco.research.bell-labs.com ([135.104.120.150]) by grubby; Fri Aug 10 10:46:08 EDT 2001 Received: (from jkf@localhost) by zydeco.research.bell-labs.com (8.9.1/8.9.1) id KAA01042; Fri, 10 Aug 2001 10:45:36 -0400 (EDT) Date: Fri, 10 Aug 2001 10:45:36 -0400 (EDT) From: Jeff Fellin Message-Id: <200108101445.KAA01042@zydeco.research.bell-labs.com> To: jkf@research.bell-labs.com, david@catwhisker.org Subject: Re: boot problems Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Sun-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 David, Answers inline with text Jeff > From david@catwhisker.org Fri Aug 10 10:36 EDT 2001 > Date: Fri, 10 Aug 2001 07:36:38 -0700 (PDT) > From: David Wolfskill > To: jkf@research.bell-labs.com > Subject: Re: boot problems > In-Reply-To: <200108101425.KAA07530@aura.research.bell-labs.com> > Content-Type: text > Content-Length: 2213 > X-Lines: 46 > > >Date: Fri, 10 Aug 2001 10:25:03 -0400 (EDT) > >From: Jeff Fellin > > >I cvsup'ed on 8/9 and did a buildworld, installworld, buildkernel, > >and installkernel. I had last cvsup'ed on 7/15 and the system worked > >fine. Now when I boot the new kernel from GENERIC, the system doesn't > >boot. The boot loader loads /boot/kernel/kernel, and when I set > >boot_verbose, and boot_ddb then boot the new kernel nothing happens. > > >I don't even get the ddb breakpoint. I haven't seen anything in > >UPDATING mentioning a problem. I'm not sure, but don't believe the > >pxeboot problem is not an issue here. > > I realize that what you wrote may well be an accurate depiction of what > you perceive... but for those of us not present to witness the > (non-)event, it can be difficult to tell from that description just how > far into the boot/loader process the machine got. > > Could you be more specific about just what is the last thing you see > displayed? The last thing displayed on the console is: set boot_ddb set boot_verbose boot Nothing else is displayed > > It may also help, at some point, to be a little more specific about when > your CVSup took place. For example, I set up the script I use to update > my local CVS repository to log records, like this: My last update from cvs was Thu Aug 9 14:07:55 EST 2001 from cvsup9.freebsd.org. The previous update was from cvsup9.freebsd.org on Mon Jul 16 08:13:42 EDT 2001 > > CVSup begin from cvsup14.freebsd.org at Mon Aug 6 03:47:00 PDT 2001 > CVSup ended from cvsup14.freebsd.org at Mon Aug 6 03:52:46 PDT 2001 > CVSup begin from cvsup14.freebsd.org at Tue Aug 7 03:47:00 PDT 2001 > CVSup ended from cvsup14.freebsd.org at Tue Aug 7 03:53:02 PDT 2001 > CVSup begin from cvsup14.freebsd.org at Wed Aug 8 03:47:00 PDT 2001 > CVSup ended from cvsup14.freebsd.org at Wed Aug 8 03:53:07 PDT 2001 > CVSup begin from cvsup14.freebsd.org at Thu Aug 9 03:47:01 PDT 2001 > CVSup ended from cvsup14.freebsd.org at Thu Aug 9 03:53:06 PDT 2001 > CVSup begin from cvsup14.freebsd.org at Fri Aug 10 03:47:01 PDT 2001 > CVSup ended from cvsup14.freebsd.org at Fri Aug 10 03:53:31 PDT 2001 > > Thus, we have bounded the period of any possible update, and know the > source of the update, as well. > > Cheers, > david > -- > David H. Wolfskill david@catwhisker.org > As a computing professional, I believe it would be unethical for me to > advise, recommend, or support the use (save possibly for personal > amusement) of any product that is or depends on any Microsoft product. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 7:50:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by hub.freebsd.org (Postfix) with ESMTP id EBE7437B405 for ; Fri, 10 Aug 2001 07:50:47 -0700 (PDT) (envelope-from mlsmith@mitre.org) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id f7AEogD25350; Fri, 10 Aug 2001 10:50:42 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id f7AEofX29772; Fri, 10 Aug 2001 10:50:41 -0400 (EDT) Received: from dhcp-48-37.mitre.org (128.29.48.37) by mailhub1.mitre.org with SMTP id 7298422; Fri, 10 Aug 2001 10:49:50 -0400 Message-ID: <3B73F595.CD12F8AA@mitre.org> Date: Fri, 10 Aug 2001 10:54:13 -0400 From: Mike Smith Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Cc: "hackers@FreeBSD.ORG" Subject: Re: the =+ operator References: <3B73F0BC.548D40B3@home.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 I've been doing this for a long time and today this would be taken as two operators. The assignment and unary +. Since A = B is the same as A = +B, it would perform the same as a simple assignment. The only reason I can see to do this legitimately is for clarity reasons, i.e., if what follows the "+" is almost always used as a negative but this use is an exception. But more likely, at some point there was something between the = and + at one point that got deleted, but the "+" was left. Since this is "the default", there would be no coding or operational errors from leaving it in. Then again, it could have been intended to be += and you've found a heretofore undiscovered bug! All you have to do is press Shift at the wrong time (not that I've ever done that). Mike Smith (but not "THE" Mike Smith) Rob wrote: > > My first post on hackers, so please don't flame me too bad :) I think > that only an old hacker can give me the answer :) > > I've searched far and wide on search engines to find out what the =+ > operator does, to no avail. I'm porting some old code and found it. I > made a test program and compiled it with gcc, and all it appears to do > is the same as regular assignment. But I'm wondering if in some day > long ago, it mean't something else? Thanks, Rob. > > 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 Fri Aug 10 8:10:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (24-241-59-156.hsacorp.net [24.241.59.156]) by hub.freebsd.org (Postfix) with ESMTP id DEDFC37B407 for ; Fri, 10 Aug 2001 08:10:22 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.3/8.11.3) id f7AFANX03749; Fri, 10 Aug 2001 11:10:23 -0400 (EDT) (envelope-from dufault) Date: Fri, 10 Aug 2001 11:09:02 -0400 From: Peter & To: Les Biffle Cc: Rob , "hackers@FreeBSD.ORG" Subject: Re: the =+ operator Message-ID: <20010810110901.A3709@hda.hda.com> References: <3B73F0BC.548D40B3@home.com> <200108101446.HAA99867@safety.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108101446.HAA99867@safety.net>; from les@safety.net on Fri, Aug 10, 2001 at 07:46:16AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 10, 2001 at 07:46:16AM -0700, Les Biffle wrote: > ... There > has never been an operator =+, even checking back to the BCPL days. Nope, check "anachronisms" in K&R, at least the 1978 edition p 212: "Earlier versions of C used the form =op instead of op= for assignment operations. This leads to ambiguities, typified by x=-1 (and so on) That would have to be REALLY old pre-1978 code to be affected. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 8:13:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail40.sdc1.sfba.home.com (femail40.sdc1.sfba.home.com [24.254.60.34]) by hub.freebsd.org (Postfix) with ESMTP id 206C337B407 for ; Fri, 10 Aug 2001 08:13:23 -0700 (PDT) (envelope-from stephen@math.missouri.edu) Received: from math.missouri.edu ([24.12.197.197]) by femail40.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010810151322.LYTJ28420.femail40.sdc1.sfba.home.com@math.missouri.edu> for ; Fri, 10 Aug 2001 08:13:22 -0700 Message-ID: <3B73FA12.CB1D140C@math.missouri.edu> Date: Fri, 10 Aug 2001 10:13:22 -0500 From: Stephen Montgomery-Smith 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: Re: Ghostscript 6.51 + HP printer = WOW! References: <6806.997424255@critter> 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 guess that you compiled it without the ports. There are some PR's awaiting to be processed at include hpijs in the port versions of ghostscript. I hope someone commits them soon. Poul-Henning Kamp wrote: > > The new ghostscript 6.51 has integrated the HPIJS backends for HP printers. > > HPIJS is written by HP and contains most of their weird colormunging technologies. > > I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I can > only say "WOW!". I beats the pants of all the other HP/PCL/whatever backends > in ghostscript. > > Highly recommended! > > -- > 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 -- Stephen Montgomery-Smith stephen@math.missouri.edu http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 8:17:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 20FC837B406 for ; Fri, 10 Aug 2001 08:17:10 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA19970; Fri, 10 Aug 2001 17:17:05 +0200 (MET DST) Date: Fri, 10 Aug 2001 17:17:05 +0200 (CEST) From: Harti Brandt To: Rob Cc: "hackers@FreeBSD.ORG" Subject: Re: the =+ operator In-Reply-To: <3B73F0BC.548D40B3@home.com> Message-ID: <20010810171127.P48634-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 10 Aug 2001, Rob wrote: R>My first post on hackers, so please don't flame me too bad :) I think R>that only an old hacker can give me the answer :) R> R>I've searched far and wide on search engines to find out what the =+ R>operator does, to no avail. I'm porting some old code and found it. I R>made a test program and compiled it with gcc, and all it appears to do R>is the same as regular assignment. But I'm wondering if in some day R>long ago, it mean't something else? Thanks, Rob. Originally the operators like += and -= where written as =+ =-. This worked at least 'til the UNIX v7 compiler. With v6 or v7 the operators were changed to get rid of the problem what 'v=-7' means. To assign -7 to v you had to write 'v= -7'. So you must have _really_ old code (much of the v7 code was still written using the old operators). harti PS: the v7 compiler also had the undocumented operators \/ and /\ for min and max. harti. PPS: if the code is not so old, it may be possible that v=+7 actually means v= +7. Note, however, that K&R has no unary +. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 8:22:23 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 1448537B403 for ; Fri, 10 Aug 2001 08:22:20 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f7AFM6f20209; Fri, 10 Aug 2001 11:22:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 10 Aug 2001 11:22:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Sansonetti Laurent Cc: freebsd-hackers@freebsd.org Subject: Re: Doing file operations on syscalls handler In-Reply-To: <003101c12195$3be399a0$0201a8c0@teledisnet.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 10 Aug 2001, Sansonetti Laurent wrote: > I'm new on FreeBSD modules programming, and I've a little question... > How can I do file operations (like open(), read()..) on a syscall > handler of a syscall module ? In fact I've met the problem since my > module must open a file which contains some informations for the hacked > syscall (in this case, it's getdirentries()).. I've tried to malloc a > open_args struct, filled-it and use [sys] open, but it doesn't work... > Is there a way to call user syscalls ? There are a couple of things to keep in mind when doing module programming: (1) Generally, filenames are with respects to a particular process's root directory or current working directory. As such, the system name->vnode calls make assumptions about the availability of that information. (2) System call code in the kernel is generally structured so that any pointers to additional data beyond the basic system call arguments are assumed to be in userspace, and associated with a particular process (generally, curproc). When kernel code interacts with files, it normally does so by operating directly on the file vnode, rather than using the indirection of the system call interface. Also, the kernel code generally relies on a userland process to initiate the name->vnode conversion, so that namei() has a process to perform the lookup with respects to (remember the need for root and working directories). Examples of file use from within kernel include ktrace(), UFS quotes, UFS extended attributes, kernel modules, and system accounting. Each of these does it a slightly different way, but all are initiated by a system call which provides an initial name to generate the vnode. 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 Fri Aug 10 8:28:10 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 C1B9237B405 for ; Fri, 10 Aug 2001 08:28:01 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f7AFS1R22251 for hackers@FreeBSD.ORG; Fri, 10 Aug 2001 11:28:01 -0400 (EDT) (envelope-from bicknell) Date: Fri, 10 Aug 2001 11:28:01 -0400 From: Leo Bicknell To: "hackers@FreeBSD.ORG" Subject: Re: the =+ operator Message-ID: <20010810112801.A21795@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , "hackers@FreeBSD.ORG" References: <3B73F0BC.548D40B3@home.com> <200108101446.HAA99867@safety.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108101446.HAA99867@safety.net>; from les@safety.net on Fri, Aug 10, 2001 at 07:46:16AM -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 Ok, I had to go try this out for my own: % cat test.c int main(void) { int a, b; a = 1; printf("a = %d\n", a); a += 1; printf("a = %d\n", a); a =+ 1; printf("a = %d\n", a); a = +1; printf("a = %d\n", a); b = 1; a =+ b; printf("a = %d\n", a); a =- b; printf("a = %d\n", a); } % cc -Wall test.c test.c: In function `main': test.c:7: warning: implicit declaration of function `printf' test.c:17: warning: control reaches end of non-void function % ./a.out a = 1 a = 2 a = 1 a = 1 a = 1 a = -1 I don't know how hard this would be to do in the compiler, but perhaps there should be a warning available for "a =+ b", but not for "a = +b". Maybe that would be better done in lint? I have to think 99% of the the times this shows up in a program it's a bug/mistake. Check out the reference below. In particular, the indent source is interesting, as is bc. % find . -name "*.[ch]" -print | xargs fgrep "=+" ./contrib/bc/bc/util.c: printf ("Old assignment operatiors are valid. (=-, =+, ...)\n"); ./contrib/cvs/src/wrapper.c: for(temp=++line;*line && (*line!='\'' || line[-1]=='\\');++line) ./contrib/libpam/libpam/pam_misc.c: for (end=++from; *end && *end != ']'; ++end) { ./contrib/nvi/vi/vs_msg.c:#define DIVIDESTR "+=+=+=+=+=+=+=+" ./contrib/tcp_wrappers/percent_x.c: static char ok_chars[] = "1234567890!@%-_=+:,./\ ./lib/libc_r/uthread/uthread_kern.c: _thread_run->last_inactive =+ ./lib/libc_r/uthread/uthread_kern.c: _thread_run->last_inactive =+ UINT_MAX + 1; ./lib/msun/src/e_asin.c: /* asin(1)=+-pi/2 with inexact */ ./lib/msun/src/e_asinf.c: /* asin(1)=+-pi/2 with inexact */ ./lib/msun/src/e_atan2.c: case 1: return y; /* atan(+-0,+anything)=+-0 */ ./lib/msun/src/e_atan2f.c: case 1: return y; /* atan(+-0,+anything)=+-0 */ ./lib/msun/src/e_rem_pio2.c: if(ix<0x4002d97c) { /* |x| < 3pi/4, special case with n=+-1 */ ./lib/msun/src/e_rem_pio2f.c: if(ix<0x4016cbe4) { /* |x| < 3pi/4, special case with n=+-1 */ ./lib/msun/src/e_sqrt.c: return x*x+x; /* sqrt(NaN)=NaN, sqrt(+inf)=+inf ./lib/msun/src/e_sqrtf.c: return x*x+x; /* sqrt(NaN)=NaN, sqrt(+inf)=+inf ./lib/msun/src/s_erf.c: return (double)(1-i)+one/x; /* erf(+-inf)=+-1 */ ./lib/msun/src/s_erff.c: return (float)(1-i)+one/x; /* erf(+-inf)=+-1 */ ./lib/msun/src/s_log1p.c: if(x==-1.0) return -two54/zero; /* log1p(-1)=+inf */ ./lib/msun/src/s_log1pf.c: if(x==(float)-1.0) return -two25/zero; /* log1p(-1)=+inf */ ./lib/msun/src/s_tanh.c: if (jx>=0) return one/x+one; /* tanh(+-inf)=+-1 */ ./lib/msun/src/s_tanhf.c: if (jx>=0) return one/x+one; /* tanh(+-inf)=+-1 */ ./release/picobsd/tinyware/oinit/oinit.c: printf("\n\n+=========================================================+\n"); ./release/picobsd/tinyware/oinit/oinit.c: printf("+=========================================================+\n\n"); ./usr.bin/indent/lexi.c: *e_token++ = '='; /* Flip =+ to += */ ./usr.bin/indent/lexi.c: *e_token++ = '='; /* Flip =+ to += */ ./usr.sbin/pcvt/vttest/main.c:ESC 1! 2@ 3# 4$ 5% 6^ 7& 8* 9( 0) -_ =+ `~ BS -- 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 Fri Aug 10 10: 4: 3 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 814E237B407 for ; Fri, 10 Aug 2001 10:03:55 -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 f7AH3sQ28265; Fri, 10 Aug 2001 10:03:54 -0700 Date: Fri, 10 Aug 2001 10:03:54 -0700 From: Brooks Davis To: Derek True Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting ti to half duplex Message-ID: <20010810100354.B22665@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sigmafour@hotmail.com on Fri, Aug 10, 2001 at 10:10:26AM -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 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 10, 2001 at 10:10:26AM -0400, Derek True wrote: >=20 > Hello, >=20 > I've posted this to freebsd-net but have a feeling I might have posted to= =20 > the wrong list. Hopefully someone here will know the resolution to the=20 > following problem: >=20 > I'm currently trying to set my 3com 3C985-SX gigabit NIC to=20 > Half-Duplex.I've recompiled FreeBSD to include the ti driver but have bee= n=20 > unsuccessful in setting it to Half-Duplex. I'm currently getting info fro= m a=20 > fiber tap which only sends and cannot recieve. When the NIC enters=20 > full-duplex mode the software I'm using on the box shuts down due to the= =20 > lack of establishing link. This can be resolved by setting the NIC to=20 > operate in half-duplex. The ti man page says see ifconfig. Ifconfig says = its=20 > a driver setting, (so go see the ti man page.) Rc.conf also has been no= =20 > help. Has anyone here dealt with the same problem? Any help is immensely= =20 > appreciated. If the card is configured to autoselect you can set it to half duplex as follows: ifconfig ti0 media 1000baseTX If it's already in full duplex mode, not autoselected, you can set it to half duplex link this: ifconfig ti0 -mediaopt full-duplex -- 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 --Bn2rw/3z4jIqBvZU 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 iD8DBQE7dBP6XY6L6fI4GtQRAuMqAKCEGwEXwZC5/Uvr5A/UaMsB0W9dhACeKTWS 9TeOmWsgw2dlIVcFhp7ZIpk= =sDy1 -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 10:47:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 1376937B403 for ; Fri, 10 Aug 2001 10:47:43 -0700 (PDT) (envelope-from rminnich@lanl.gov) Received: from snaresland.acl.lanl.gov (snaresland.acl.lanl.gov [128.165.147.113]) by acl.lanl.gov (8.11.3/8.8.5) with SMTP id f7AHlgO2306871 for ; Fri, 10 Aug 2001 11:47:42 -0600 (MDT) Received: (qmail 17111 invoked by uid 3499); 10 Aug 2001 17:47:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Aug 2001 17:47:42 -0000 Date: Fri, 10 Aug 2001 11:47:42 -0600 (MDT) From: Ronald G Minnich X-X-Sender: To: Rob Cc: "hackers@FreeBSD.ORG" Subject: Re: the =+ operator In-Reply-To: <3B73F0BC.548D40B3@home.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 Fri, 10 Aug 2001, Rob wrote: > I've searched far and wide on search engines to find out what the =+ > operator does, to no avail. it's the predecessor to +=. It's the reason people put spaces around the '=' sign in C, going back to this old way of doing a +=. If you can find some old ca. 1976 Unix V6 documents, you'll find the description in there. Sorry, you can't have mine. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 11:15:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tepid.osl.fast.no (tepid.osl.fast.no [213.188.9.130]) by hub.freebsd.org (Postfix) with ESMTP id B543F37B403 for ; Fri, 10 Aug 2001 11:15:15 -0700 (PDT) (envelope-from raw@fast.no) Received: from raw.grenland.fast.no (fw-oslo.fast.no [213.188.9.129]) by tepid.osl.fast.no (8.9.3/8.9.1) with ESMTP id UAA01996; Fri, 10 Aug 2001 20:15:10 +0200 (CEST) (envelope-from raw@fast.no) Received: (from raw@localhost) by raw.grenland.fast.no (8.11.3/8.11.3) id f7AIF6Z83290; Fri, 10 Aug 2001 20:15:06 +0200 (CEST) (envelope-from raw) From: Raymond Wiker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15220.9386.441669.962830@raw.grenland.fast.no> Date: Fri, 10 Aug 2001 20:15:06 +0200 To: les@safety.net Cc: europax@home.com (Rob), hackers@FreeBSD.ORG (hackers@FreeBSD.ORG) Subject: Re: the =+ operator In-Reply-To: <200108101446.HAA99867@safety.net> References: <3B73F0BC.548D40B3@home.com> <200108101446.HAA99867@safety.net> X-Mailer: VM 6.92 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Les Biffle writes: > > My first post on hackers, so please don't flame me too bad :) I think > > that only an old hacker can give me the answer :) > > > > I've searched far and wide on search engines to find out what the =+ > > operator does, to no avail. I'm porting some old code and found it. > > I ran into this a couple of times, and it was always a typo by the > programmer. Whether they meant to use "+=" or not wasn't always > clear. In C, you should imagine reading the code with all of the > non-quoted white space removed to see how the compiler will treat > something, so "a =+ 1;" is the same as "a=+1;" or "a = +1;" There > has never been an operator =+, even checking back to the BCPL days. > > So, read the code carefully to see if you can figure out if they > meant += This is actually wrong - the += and -= operators were originally written as =+ and =-. This is obviously ambiguous, given the fact that whitespace is ignored. //Raymond. -- Raymond Wiker Raymond.Wiker@fast.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 12:40:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id D0C1D37B407 for ; Fri, 10 Aug 2001 12:40:20 -0700 (PDT) (envelope-from rminnich@lanl.gov) Received: from snaresland.acl.lanl.gov (snaresland.acl.lanl.gov [128.165.147.113]) by acl.lanl.gov (8.11.3/8.8.5) with SMTP id f7AJeKO2306859 for ; Fri, 10 Aug 2001 13:40:20 -0600 (MDT) Received: (qmail 17502 invoked by uid 3499); 10 Aug 2001 19:40:19 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Aug 2001 19:40:19 -0000 Date: Fri, 10 Aug 2001 13:40:19 -0600 (MDT) From: Ronald G Minnich X-X-Sender: To: Raymond Wiker Cc: , Rob , "hackers@FreeBSD.ORG" Subject: Re: the =+ operator In-Reply-To: <15220.9386.441669.962830@raw.grenland.fast.no> 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 Fri, 10 Aug 2001, Raymond Wiker wrote: > This is actually wrong - the += and -= operators were > originally written as =+ and =-. This is obviously ambiguous, given > the fact that whitespace is ignored. that was the problem. In this one case, in the old C compilers, white space mattered. hence the habit many of us have of putting ' = ' in our code. It's stylistic now, but back then it was a source of bugs in programs, i.e. '=-' was not the same meaning as ' = -' ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 14:32:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 6A56137B406 for ; Fri, 10 Aug 2001 14:32:46 -0700 (PDT) (envelope-from float@firedrake.org) Received: from float by dayspring.firedrake.org with local (Exim 3.22 #1 (Debian)) id 15VJtO-000877-00; Fri, 10 Aug 2001 22:32:30 +0100 Date: Fri, 10 Aug 2001 22:32:30 +0100 To: Ronald G Minnich Cc: Rob , "hackers@FreeBSD.ORG" Subject: Re: the =+ operator Message-ID: <20010810223230.A30923@firedrake.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: void Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 10, 2001 at 11:47:42AM -0600, Ronald G Minnich wrote: > > it's the predecessor to +=. It's the reason people put spaces around the > '=' sign in C, going back to this old way of doing a +=. If you can find > some old ca. 1976 Unix V6 documents, you'll find the description in there. > Sorry, you can't have mine. http://www.peer-to-peer.com/catalog/opsrc/lions.html -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 15:47:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 3459A37B405 for ; Fri, 10 Aug 2001 15:47:48 -0700 (PDT) (envelope-from boshea@netapp.com) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7AMkWX13727; Fri, 10 Aug 2001 15:46:32 -0700 (PDT) Received: from eclipse-fe.eng.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7AMkWw00911; Fri, 10 Aug 2001 15:46:32 -0700 (PDT) Received: (from boshea@localhost) by eclipse-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id PAA19617; Fri, 10 Aug 2001 15:46:31 -0700 (PDT) Date: Fri, 10 Aug 2001 15:46:30 -0700 From: "brian o'shea" To: Raymond Wiker Cc: les@safety.net, Rob , "hackers@FreeBSD.ORG" Subject: Re: the =+ operator Message-ID: <20010810154630.A27553@netapp.com> References: <3B73F0BC.548D40B3@home.com> <200108101446.HAA99867@safety.net> <15220.9386.441669.962830@raw.grenland.fast.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <15220.9386.441669.962830@raw.grenland.fast.no>; from Raymond Wiker on Fri, Aug 10, 2001 at 08:15:06PM +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 Fri, Aug 10, 2001 at 08:15:06PM +0200, Raymond Wiker wrote: > > This is actually wrong - the += and -= operators were > originally written as =+ and =-. This is obviously ambiguous, given > the fact that whitespace is ignored. Why does this have to be ambiguous? Consider this: int o = 2; int *p = &o; int q = 8; int r; r = q/*p /* comment */; printf("r == %d\n", r); Is this equivalent to the following: r = q / *p; Or is it equivalent to this: r = q /* p /* comment */ ; C disambiguates between these two possible interpretations by matching the largest possible token. Thus, it is taken to be equivalent to: r = q; In other words, these two lines are not equivalent: r = q/*p /* comment */; r = q/ *p /* comment */; So, the =+ operator could be interprited correctly as long as it is the largest possible token. It does leave more of an opportunity for human misinterpritation, while my example is less likely to be seen. -brian -- Brian O'Shea "Stare not too deeply into the pen, 3.3.163(PEN) lest the pen stare back into you." (408) 822-3249 -------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 17:24:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail38.sdc1.sfba.home.com (femail38.sdc1.sfba.home.com [24.254.60.32]) by hub.freebsd.org (Postfix) with ESMTP id 0EB7A37B406 for ; Fri, 10 Aug 2001 17:24:23 -0700 (PDT) (envelope-from europax@home.com) Received: from home.com ([24.12.186.185]) by femail38.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010811002422.OJTR24947.femail38.sdc1.sfba.home.com@home.com>; Fri, 10 Aug 2001 17:24:22 -0700 Message-ID: <3B747B35.CCA4C6D1@home.com> Date: Fri, 10 Aug 2001 17:24:22 -0700 From: Rob X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: "hackers@FreeBSD.ORG" Subject: Re: the =+ operator References: <3B73F0BC.548D40B3@home.com> <3B73F595.CD12F8AA@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > > I've been doing this for a long time and today this would be taken as > two operators. The assignment and unary +. Since A = B is the same as A > = +B, it would perform the same as a simple assignment. The only reason > I can see to do this legitimately is for clarity reasons, i.e., if what > follows the "+" is almost always used as a negative but this use is an > exception. But more likely, at some point there was something between > the = and + at one point that got deleted, but the "+" was left. Since > this is "the default", there would be no coding or operational errors > from leaving it in. > > Then again, it could have been intended to be += and you've found a > heretofore undiscovered bug! All you have to do is press Shift at the > wrong time (not that I've ever done that). > > Mike Smith > (but not "THE" Mike Smith) > > Rob wrote: > > > > My first post on hackers, so please don't flame me too bad :) I think > > that only an old hacker can give me the answer :) > > > > I've searched far and wide on search engines to find out what the =+ > > operator does, to no avail. I'm porting some old code and found it. I > > made a test program and compiled it with gcc, and all it appears to do > > is the same as regular assignment. But I'm wondering if in some day > > long ago, it mean't something else? Thanks, Rob. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message Thanks Mike, also thanks for everyone elses response. This code is actually pretty new. It part of a bi-gradient conjugate solver for FEM simulators. I compiled the original code with gcc, so I'm assuming it just treated =+ as an =. But just for kicks I also tried +=. In any case I have some other bugs in it that I have to track down since no-matter which way I tried the assignment, my solutions fail to converge :( Rob. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 17:51: 4 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 EA32A37B403 for ; Fri, 10 Aug 2001 17:50:58 -0700 (PDT) (envelope-from jan@digitaldaemon.com) Received: (qmail 93403 invoked from network); 11 Aug 2001 00:48:50 -0000 Received: from unknown (HELO digitaldaemon.com) (192.168.0.73) by digitaldaemon.com with SMTP; 11 Aug 2001 00:48:50 -0000 Message-ID: <3B7480E7.6070406@digitaldaemon.com> Date: Fri, 10 Aug 2001 20:48:39 -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: Re: the =+ operator References: <3B73F0BC.548D40B3@home.com> <3B73F595.CD12F8AA@mitre.org> <3B747B35.CCA4C6D1@home.com> Content-Type: multipart/alternative; boundary="------------000401060602010107040906" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --------------000401060602010107040906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I just checked on this "=+" and "=-" with the guy that wrote the first native C++ compiler and he does not recall it at first being that way... I have been programming C++ myself for over 10 years and *never* heard this before. I do not know where it comes from. It might have been some mis-implemented C++ syntax in other C++ compilers (GNU?). Need less to say, '=+' as operator would be scary as it is too close to '= +' as in a=+5 or a=-5 for that matter. I have too much respect for Bjarne to think that he would have defined it as '=+' and '=-' in the beginning... Just my two cents. Jan Rob wrote: >Mike Smith wrote: > >>I've been doing this for a long time and today this would be taken as >>two operators. The assignment and unary +. Since A = B is the same as A >>= +B, it would perform the same as a simple assignment. The only reason >>I can see to do this legitimately is for clarity reasons, i.e., if what >>follows the "+" is almost always used as a negative but this use is an >>exception. But more likely, at some point there was something between >>the = and + at one point that got deleted, but the "+" was left. Since >>this is "the default", there would be no coding or operational errors >>from leaving it in. >> >>Then again, it could have been intended to be += and you've found a >>heretofore undiscovered bug! All you have to do is press Shift at the >>wrong time (not that I've ever done that). >> >>Mike Smith >>(but not "THE" Mike Smith) >> >>Rob wrote: >> >>>My first post on hackers, so please don't flame me too bad :) I think >>>that only an old hacker can give me the answer :) >>> >>>I've searched far and wide on search engines to find out what the =+ >>>operator does, to no avail. I'm porting some old code and found it. I >>>made a test program and compiled it with gcc, and all it appears to do >>>is the same as regular assignment. But I'm wondering if in some day >>>long ago, it mean't something else? Thanks, Rob. >>> >>>To Unsubscribe: send mail to majordomo@FreeBSD.org >>>with "unsubscribe freebsd-hackers" in the body of the message >>> > >Thanks Mike, also thanks for everyone elses response. This code is >actually pretty new. It part of a bi-gradient conjugate solver for FEM >simulators. I compiled the original code with gcc, so I'm assuming it >just treated =+ as an =. But just for kicks I also tried +=. In any >case I have some other bugs in it that I have to track down since >no-matter which way I tried the assignment, my solutions fail to >converge :( Rob. > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > > --------------000401060602010107040906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I just checked on this "=+" and "=-" with the guy that wrote the first native C++ compiler and he does not recall it at first being that way... I have been programming C++ myself for over 10 years and *never* heard this before. I do not know where it comes from. It might have been some mis-implemented C++ syntax in other C++ compilers (GNU?). Need less to say, '=+' as operator would be scary as it is too close to '= +' as in a=+5 or a=-5 for that matter. I have too much respect for Bjarne to think that he would have defined it as '=+' and '=-' in the beginning...

Just my two cents.
Jan



Rob wrote:
Mike Smith wrote:
I've been doing this for a long time and today this would be taken as
two operators. The assignment and unary +. Since A = B is the same as A
= +B, it would perform the same as a simple assignment. The only reason
I can see to do this legitimately is for clarity reasons, i.e., if what
follows the "+" is almost always used as a negative but this use is an
exception. But more likely, at some point there was something between
the = and + at one point that got deleted, but the "+" was left. Since
this is "the default", there would be no coding or operational errors
from leaving it in.

Then again, it could have been intended to be += and you've found a
heretofore undiscovered bug! All you have to do is press Shift at the
wrong time (not that I've ever done that).

Mike Smith
(but not "THE" Mike Smith)

Rob wrote:
My first post on hackers, so please don't flame me too bad :)  I think
that only an old hacker can give me the answer :)

I've searched far and wide on search engines to find out what the =+
operator does, to no avail.  I'm porting some old code and found it.  I
made a test program and compiled it with gcc, and all it appears to do
is the same as regular assignment.  But I'm wondering if in some day
long ago, it mean't something else?  Thanks,  Rob.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message

Thanks Mike, also thanks for everyone elses response.  This code is
actually pretty new.  It part of a bi-gradient conjugate solver for FEM
simulators.  I compiled the original code with gcc, so I'm assuming it
just treated =+ as an =.  But just for kicks I also tried +=.  In any
case I have some other bugs in it that I have to track down since
no-matter which way I tried the assignment, my solutions fail to
converge :(           Rob.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



--------------000401060602010107040906-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 18:14:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from neptune.he.net (neptune.he.net [216.218.166.2]) by hub.freebsd.org (Postfix) with ESMTP id 2190B37B401; Fri, 10 Aug 2001 18:14:42 -0700 (PDT) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com ([210.52.155.72] (may be forged)) by neptune.he.net (8.8.6/8.8.2) with ESMTP id SAA18279; Fri, 10 Aug 2001 18:14:46 -0700 Received: (from robinson@localhost) by netrinsics.com (8.11.2/8.11.1) id f7B1F4100321; Sat, 11 Aug 2001 09:15:04 +0800 (+0800) (envelope-from robinson) Date: Sat, 11 Aug 2001 09:15:04 +0800 (+0800) From: Michael Robinson Message-Id: <200108110115.f7B1F4100321@netrinsics.com> To: current@freebsd.org Subject: _sigprocmask in malloc.c causes full file table? 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 I'm currently trying to deal with the problem where malloc/free in a signal handler will crash (in my case, the X window server) if a signal arrives during malloc or free. Following the example of, e.g., stdlib/system.c, I tried blocking the usual suspects (SIGIO, SIGWINCH, etc.), as follows: void free(void *ptr) { sigset_t old_procmask; THREAD_LOCK(); _sigprocmask(SIG_BLOCK, &malloc_procmask, &old_procmask); malloc_func = " in free():"; if (malloc_active++) { wrtwarning("recursive call.\n"); } else { ifree(ptr); UTRACE(ptr, 0, 0); } malloc_active--; _sigprocmask(SIG_SETMASK, &old_procmask, NULL); THREAD_UNLOCK(); return; } That worked for the general case, but it broke mozilla in an interesting way; mozilla would fail to create a kernel pipe in uthread_init.c, and I would get a system error: Aug 11 07:33:25 elephant /boot/kernel/kernel: file: table is full Aug 11 07:33:25 elephant /boot/kernel/kernel: pid 358 (mozilla-bin), uid 1000: exited on signal 6 (core dumped) I then changed the initialization of malloc_procmask so that it contained no signals whatsoever, and the exact same thing happened. I then commented out all calls to sigprocmask, and everything returned to normal. Am I doing something completely boneheaded, or is this an undocumented subtle interaction? -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 19: 4: 8 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 E9A7237B41D; Fri, 10 Aug 2001 19:03:58 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CFE1C81D05; Fri, 10 Aug 2001 21:03:48 -0500 (CDT) Date: Fri, 10 Aug 2001 21:03:48 -0500 From: Alfred Perlstein To: Michael Robinson Cc: current@freebsd.org, hackers@freebsd.org Subject: Re: _sigprocmask in malloc.c causes full file table? Message-ID: <20010810210348.T85642@elvis.mu.org> References: <200108110115.f7B1F4100321@netrinsics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108110115.f7B1F4100321@netrinsics.com>; from robinson@netrinsics.com on Sat, Aug 11, 2001 at 09:15:04AM +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 * Michael Robinson [010810 20:17] wrote: > I'm currently trying to deal with the problem where malloc/free in a > signal handler will crash (in my case, the X window server) if a signal > arrives during malloc or free. Yes, you are not supposed to call malloc/free from a signal handler unless you know exactly what you're doing when you do so. > Am I doing something completely boneheaded, or is this an undocumented > subtle interaction? You're expecting calls to free/malloc to work from within an async signal handler, so yes, you're being a bit boneheaded. :) -- -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 Fri Aug 10 19:30:20 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 04AB137B407 for ; Fri, 10 Aug 2001 19:30: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 f7B2UGl15998; Fri, 10 Aug 2001 20:30:16 -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 f7B2UG140366; Fri, 10 Aug 2001 20:30:16 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108110230.f7B2UG140366@harmony.village.org> To: Rob Subject: Re: the =+ operator Cc: "hackers@FreeBSD.ORG" In-reply-to: Your message of "Fri, 10 Aug 2001 07:33:32 PDT." <3B73F0BC.548D40B3@home.com> References: <3B73F0BC.548D40B3@home.com> Date: Fri, 10 Aug 2001 20:30:15 -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 <3B73F0BC.548D40B3@home.com> Rob writes: : I've searched far and wide on search engines to find out what the =+ : operator does, to no avail. I'm porting some old code and found it. I Nothing. It used to do the same thing that += does today. a += b; /* same as a = a + (b); */ Wanrer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 20: 4:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dorothy.hentschel.net (w002.z064221160.smf-ca.dsl.cnc.net [64.221.160.2]) by hub.freebsd.org (Postfix) with ESMTP id 9080837B403 for ; Fri, 10 Aug 2001 20:04:10 -0700 (PDT) (envelope-from thomas@hentschel.net) Received: from hentschel.net (user@falcon.home.hentschel.net [192.168.1.2]) by dorothy.hentschel.net (8.8.8/8.8.8) with ESMTP id UAA04262; Fri, 10 Aug 2001 20:01:32 -0700 (PDT) (envelope-from thomas@hentschel.net) Message-Id: <200108110301.UAA04262@dorothy.hentschel.net> Date: Fri, 10 Aug 2001 20:04:51 -0700 (PDT) From: thomas@hentschel.net Subject: Re: Ghostscript 6.51 + HP printer = WOW! To: Stephen Montgomery-Smith Cc: hackers@FreeBSD.ORG In-Reply-To: <3B73FA12.CB1D140C@math.missouri.edu> 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 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28846 say's that it was commited yesterday :) compiling right now .... -Th On 10 Aug, Stephen Montgomery-Smith wrote: > I guess that you compiled it without the ports. There are some PR's > awaiting to be processed at include hpijs in the port versions of > ghostscript. I hope someone commits them soon. > > Poul-Henning Kamp wrote: >> >> The new ghostscript 6.51 has integrated the HPIJS backends for HP printers. >> >> HPIJS is written by HP and contains most of their weird colormunging technologies. >> >> I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I can >> only say "WOW!". I beats the pants of all the other HP/PCL/whatever backends >> in ghostscript. >> >> Highly recommended! >> >> -- >> 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 20:11:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout6.nyroc.rr.com (mailout6-0.nyroc.rr.com [24.92.226.125]) by hub.freebsd.org (Postfix) with ESMTP id B480037B407 for ; Fri, 10 Aug 2001 20:11:37 -0700 (PDT) (envelope-from assem@twcny.rr.com) Received: from twcny.rr.com (syr-24-92-246-130.twcny.rr.com [24.92.246.130]) by mailout6.nyroc.rr.com (8.11.2/RoadRunner 1.03) with ESMTP id f7B3BJ707673 for ; Fri, 10 Aug 2001 23:11:32 -0400 (EDT) Message-ID: <3B74A0F8.68E02C78@twcny.rr.com> Date: Fri, 10 Aug 2001 23:05:28 -0400 From: Assem Salama X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: dma_tag_create 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, What is the meaning of the maxsegsz argument of dma_tag_create? It doesn't seam to have any effect. This is my code: /* try to allocate some DMA memory */ if(bus_dma_tag_create( NULL, /* parent */ (1<<16), /* allignment (64K) */ (0), /* boundry */ BUS_SPACE_MAXSIZE_32BIT,/* lowaddr */ BUS_SPACE_MAXSIZE, /* high addr */ NULL, NULL, /* filter, filterarg */ (1<<14), /* maxsize (256K) */ 4, /* num segs */ (1<<10), /* maxsegsize */ 0, &dma_tag)) { PRINTERR("Could not make the DMA tag!\n"); return ENXIO; } if(bus_dmamem_alloc(dma_tag, (void*)&DMA_buffer, BUS_DMA_NOWAIT, &dma_map)) { PRINTERR("Could not allocate memory!\n"); bus_dma_tag_destroy(dma_tag); return ENXIO; } if(bus_dmamap_load(dma_tag, dma_map, DMA_buffer, (1<<12), ide_mod_load_map, &phys_addr, 0)) { PRINTERR("Could not load the map!\n"); bus_dmamem_free(dma_tag, DMA_buffer, dma_map); bus_dma_tag_destroy(dma_tag); return ENXIO; } Thanks, Assem Salama To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 20:13: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail47.sdc1.sfba.home.com (femail47.sdc1.sfba.home.com [24.254.60.41]) by hub.freebsd.org (Postfix) with ESMTP id 6EABF37B401 for ; Fri, 10 Aug 2001 20:13:05 -0700 (PDT) (envelope-from stephen@math.missouri.edu) Received: from math.missouri.edu ([24.12.197.197]) by femail47.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010811031305.SMDS26833.femail47.sdc1.sfba.home.com@math.missouri.edu>; Fri, 10 Aug 2001 20:13:05 -0700 Message-ID: <3B74A2C0.E6D8654A@math.missouri.edu> Date: Fri, 10 Aug 2001 22:13:04 -0500 From: Stephen Montgomery-Smith X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: thomas@hentschel.net Cc: hackers@FreeBSD.ORG Subject: Re: Ghostscript 6.51 + HP printer = WOW! References: <200108110301.UAA04262@dorothy.hentschel.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I read that it was closed because it was supersceded by 29579 thomas@hentschel.net wrote: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28846 say's that it was > commited yesterday :) > > compiling right now .... > > -Th > > On 10 Aug, Stephen Montgomery-Smith wrote: > > I guess that you compiled it without the ports. There are some PR's > > awaiting to be processed at include hpijs in the port versions of > > ghostscript. I hope someone commits them soon. > > > > Poul-Henning Kamp wrote: > >> > >> The new ghostscript 6.51 has integrated the HPIJS backends for HP printers. > >> > >> HPIJS is written by HP and contains most of their weird colormunging technologies. > >> > >> I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I can > >> only say "WOW!". I beats the pants of all the other HP/PCL/whatever backends > >> in ghostscript. > >> > >> Highly recommended! > >> > >> -- > >> 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 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Stephen Montgomery-Smith stephen@math.missouri.edu http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 20:44:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from neptune.he.net (neptune.he.net [216.218.166.2]) by hub.freebsd.org (Postfix) with ESMTP id 02B9037B401; Fri, 10 Aug 2001 20:44:16 -0700 (PDT) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com ([210.52.157.5] (may be forged)) by neptune.he.net (8.8.6/8.8.2) with ESMTP id UAA09684; Fri, 10 Aug 2001 20:44:21 -0700 Received: (from robinson@localhost) by netrinsics.com (8.11.2/8.11.1) id f7B3iWx00491; Sat, 11 Aug 2001 11:44:32 +0800 (+0800) (envelope-from robinson) Date: Sat, 11 Aug 2001 11:44:32 +0800 From: Michael Robinson To: Alfred Perlstein Cc: current@freebsd.org, hackers@freebsd.org Subject: Re: _sigprocmask in malloc.c causes full file table? Message-ID: <20010811114432.A472@elephant.netrinsics.com> References: <200108110115.f7B1F4100321@netrinsics.com> <20010810210348.T85642@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: <20010810210348.T85642@elvis.mu.org>; from bright@mu.org on Fri, Aug 10, 2001 at 09:03:48PM -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 Fri, Aug 10, 2001 at 09:03:48PM -0500, Alfred Perlstein wrote: > You're expecting calls to free/malloc to work from within an async > signal handler, so yes, you're being a bit boneheaded. :) Well, actually, I'm just expecting XFree86 4.1 to run under FreeBSD without randomly crashing. I tried fixing XFree86, but there are no less than three different memory allocation abstractions (maybe more, I got lost after a while), the interrupt-handling abstraction layer makes it almost impossible to find which code handles which interrupts, and the FreeBSD OS-specific code is a complete mess. So, I decided to take the easy way out and just disable interrupts in malloc/free. There are other parts of libc that have interrupts disabled, so is there any reason in principle this shouldn't work? -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 21:43:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id DAE4637B40B; Fri, 10 Aug 2001 21:43:20 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NHPRWWM3; Sat, 11 Aug 2001 08:34:33 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f7B4hBu39151; Sat, 11 Aug 2001 08:43:11 +0400 (MSD) (envelope-from yar) Date: Sat, 11 Aug 2001 08:43:10 +0400 From: Yar Tikhiy To: hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: finger/fingerd & home directory permissions Message-ID: <20010811084310.B29956@comp.chem.msu.su> References: <20010809020831.B44660@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010809020831.B44660@comp.chem.msu.su>; from yar@FreeBSD.ORG on Thu, Aug 09, 2001 at 02:08:31AM +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 Thu, Aug 09, 2001 at 02:08:31AM +0400, Yar Tikhiy wrote: > > Currently, finger(1) reveals user information if the user > has created the ``.nofinger'' file, but his home directory > is unreadable for finger(1). > > In the case of local access, it's no problem, since anyone may read > /etc/passwd directly. OTOH, letting remote folks peek at user > information even if the user wants to hide himself is a bad thing. > > The issue I'd like to submit to discussion is what way to choose: > > a) Add a command-line option to finger(1) and fingerd(8) telling > them not to reveal user information if the user's homedir is > protected. > > b) Similar to a), but hide such users by default. > > c) Don't bother at all :-) Thank everyone for your suggestions and comments. I'm going to take the a) way. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 10 22:18: 5 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 C9F7E37B401; Fri, 10 Aug 2001 22:17:58 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA89899; Fri, 10 Aug 2001 22:02:09 -0700 (PDT) Message-ID: <3B74BA9E.A4ED7A00@elischer.org> Date: Fri, 10 Aug 2001 21:54:54 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Michael Robinson Cc: current@freebsd.org, hackers@freebsd.org Subject: Re: _sigprocmask in malloc.c causes full file table? References: <200108110115.f7B1F4100321@netrinsics.com> Content-Type: text/plain; charset=iso-8859-2 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 Michael Robinson wrote: > > Am I doing something completely boneheaded, or is this an undocumented > subtle interaction? Malloc is not re-entrant...i.e. you cannot use in in a signal handler.. > > -Michael Robinson > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 2:43:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dorothy.hentschel.net (w002.z064221160.smf-ca.dsl.cnc.net [64.221.160.2]) by hub.freebsd.org (Postfix) with ESMTP id 5FC9937B435 for ; Sat, 11 Aug 2001 02:43:13 -0700 (PDT) (envelope-from thomas@hentschel.net) Received: from hentschel.net (user@falcon.home.hentschel.net [192.168.1.2]) by dorothy.hentschel.net (8.8.8/8.8.8) with ESMTP id CAA09338; Sat, 11 Aug 2001 02:40:50 -0700 (PDT) (envelope-from thomas@hentschel.net) Message-Id: <200108110940.CAA09338@dorothy.hentschel.net> Date: Sat, 11 Aug 2001 02:44:10 -0700 (PDT) From: thomas@hentschel.net Subject: Re: Ghostscript 6.51 + HP printer = WOW! To: Stephen Montgomery-Smith Cc: hackers@FreeBSD.ORG In-Reply-To: <3B74A2C0.E6D8654A@math.missouri.edu> 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 You're right. Where are the committers when you need them :) [ /me thinks they are busy talking about someones email address in ssh :| ] -Th On 10 Aug, Stephen Montgomery-Smith wrote: > I read that it was closed because it was supersceded by 29579 > > thomas@hentschel.net wrote: >> >> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28846 say's that it was >> commited yesterday :) >> >> compiling right now .... >> >> -Th >> >> On 10 Aug, Stephen Montgomery-Smith wrote: >> > I guess that you compiled it without the ports. There are some PR's >> > awaiting to be processed at include hpijs in the port versions of >> > ghostscript. I hope someone commits them soon. >> > >> > Poul-Henning Kamp wrote: >> >> >> >> The new ghostscript 6.51 has integrated the HPIJS backends for HP printers. >> >> >> >> HPIJS is written by HP and contains most of their weird colormunging technologies. >> >> >> >> I managed to compile a 6.51 yesterday and ran it on my HP1220C printer and I can >> >> only say "WOW!". I beats the pants of all the other HP/PCL/whatever backends >> >> in ghostscript. >> >> >> >> Highly recommended! >> >> >> >> -- >> >> 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 >> > >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 7:22: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 9B59337B407 for ; Sat, 11 Aug 2001 07:22:01 -0700 (PDT) (envelope-from kevin@caomhin.demon.co.uk) Received: from caomhin.demon.co.uk ([212.228.234.119]) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15VZeJ-000D7Y-0Y for freebsd-hackers@freebsd.org; Sat, 11 Aug 2001 15:22:00 +0100 Message-ID: Date: Sat, 11 Aug 2001 15:18:52 +0100 To: freebsd-hackers@freebsd.org From: Kevin Golding Subject: Apache modules failing to load MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 U Sender: owner-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 been having a lot of trouble upgrading Apache since I upgraded FreeBSD 4.2 -> 4.3 (release) I'm trying to get mod_ssl and PHP4 to run, (mod_perl is an added bonus too but less important) I've tried installing the apache+modssl package but I just get a vanilla apache, I've tried forgetting about ssl and just installing PHP4 but I still just get plain Apache. I reinstalled mm to make sure that wasn't playing up but I'm still getting the same problem. The biggest clue to what's going on is when I run make in apache13-modssl from the ports tree. It produces this selection of errors that I can't fathom out: 4 -DEAPI -DEAPI_MM -DUSE_EXPAT -I../lib/expat-lite -O -pipe `../apaci` alloc.c alloc.c:146: syntax error before `*' alloc.c:146: warning: data definition has no type or storage class alloc.c: In function `free_blocks': alloc.c:324: `AP_MM_LOCK_RW' undeclared (first use in this function) alloc.c:324: (Each undeclared identifier is reported only once alloc.c:324: for each function it appears in.) alloc.c: In function `make_sub_pool_internal': alloc.c:503: `AP_MM_LOCK_RW' undeclared (first use in this function) alloc.c: In function `ap_init_alloc_shared': alloc.c:626: `EAPI_MM_CORE_MAXSIZE' undeclared (first use in this function) alloc.c:631: warning: assignment makes pointer from integer without a cast alloc.c:633: warning: assignment makes pointer from integer without a cast alloc.c: In function `ap_clear_pool': alloc.c:679: `AP_MM_LOCK_RW' undeclared (first use in this function) alloc.c: In function `ap_destroy_pool': alloc.c:724: `AP_MM_LOCK_RW' undeclared (first use in this function) alloc.c: At top level: alloc.c:755: syntax error before `ap_pool_lock_mode' alloc.c: In function `ap_acquire_pool': alloc.c:758: `p' undeclared (first use in this function) alloc.c:760: `mode' undeclared (first use in this function) alloc.c:760: `AP_POOL_RD' undeclared (first use in this function) alloc.c:760: `AP_MM_LOCK_RD' undeclared (first use in this function) alloc.c:760: `AP_MM_LOCK_RW' undeclared (first use in this function) alloc.c: In function `ap_palloc': alloc.c:945: `AP_MM_LOCK_RW' undeclared (first use in this function) alloc.c: In function `psprintf_flush': alloc.c:1106: `AP_MM_LOCK_RW' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/www/apache13-modssl/work/apache_1.3.20/src/main. *** Error code 1 Stop in /usr/ports/www/apache13-modssl/work/apache_1.3.20/src. *** Error code 1 Stop in /usr/ports/www/apache13-modssl/work/apache_1.3.20. *** Error code 1 Stop in /usr/ports/www/apache13-modssl/work/apache_1.3.20. *** Error code 1 Stop in /usr/ports/www/apache13-modssl. *** Error code 1 Stop in /usr/ports/www/apache13-modssl. *** Error code 1 Stop in /usr/ports/www/apache13-modssl. Any advice or ideas will be greatly appreciated, Kevin -- kevin@caomhin.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 11:44:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id E2FF437B405 for ; Sat, 11 Aug 2001 11:43:58 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.88.Dial1.SanJose1.Level3.net [209.245.135.88]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA29090; Sat, 11 Aug 2001 11:43:56 -0700 (PDT) Message-ID: <3B757D14.B344931@mindspring.com> Date: Sat, 11 Aug 2001 11:44:36 -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: Rob Cc: "hackers@FreeBSD.ORG" Subject: Re: the =+ operator References: <3B73F0BC.548D40B3@home.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 Rob wrote: > I've searched far and wide on search engines to find out what the =+ > operator does, to no avail. I'm porting some old code and found it. I > made a test program and compiled it with gcc, and all it appears to do > is the same as regular assignment. But I'm wondering if in some day > long ago, it mean't something else? Thanks, Rob. Before ANSI went and ruined everything (e.g. by adding prototypes instead of making the object file format store attribution data, and smarter linkers, because the committee was packed with compiler vendors who wanted to do good on benchmarks), there was K&R C. In K&R C, the one true C, token gathering was two pass; it did not ingnore whitespace for token seperation on the first pass, and ignored it on the second, when necessary to disambiguate unknown tokens. Historically, the =+ and =- operators were used in the original C compilers... I believe this was for weenies who were unfortunate enough to own HP calculators, but it was an anacronism even 1978, which is when my copy of "The C Programming Language" book was published (unfortunately, it's not a first printing); this is noted on page 212, where they also talk about no "=" initializers ("int i 1;" instead of "int i = 1;"; newer, dumber, compilers have a hard time disambiguating expressions like "int i (17+BOO);" from functions because of the one pass tokenizer, so this is not allowed by ANSI, either). I have used many compilers that took "=-", "=+", "=/", "=*", "=>>", etc., etc.. ANSI broke all this code when it stated that whitespace was always ignored (thus permitting compiler writers to do single pass token gathering using the "greedy" rule, which could be done with a single pass LALR parser, spitting out tokens when the next character could not possibly be part of the previous token). I have also seen the "/\" (max), "\/" (min), and "^^" (McCarthy XOR, moral symmetry for the McCarthy "||", "&&" operators), since the compilers that used them could put them into single machine instructions). My Manx Aztec C compiler for the IBM PC supports "=+" and "=-"; it is also smart enought to turn: "x * 10" into "x <<=2; x++; x<<=1", and the 68000 version was smart enough to realize the bus was 16 bits, not 32 bits, and so made "int" 16 bits on the 68000, but 32 bits on the 68k processors with 32 bit busses, resulting in single cycle transfer times for the data: most other compilers, (e.g. Lattice C), were stupid, and made int 32 bits to appease lousy programmers. Something to think about, for you "style" wonks who insist on "if ((a+=5))" instead of "if( a += 5)", not realizing that butting up the parenthesis left associatively is required to make some compilers work right, and the doubled parenthesis are just an editorial comment by the compiler writers about their preferred style of doing the test after the operation ("a += 5; if(a)"), coming from being assembly weenies, and not really something wrong, when they bitch about assignments in comparison statements. Kids these days: change the programmer to fit the machine... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 12: 5:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 2763237B409; Sat, 11 Aug 2001 12:05:45 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.88.Dial1.SanJose1.Level3.net [209.245.135.88]) by robin.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA13417; Sat, 11 Aug 2001 12:05:43 -0700 (PDT) Message-ID: <3B75822F.E84799BD@mindspring.com> Date: Sat, 11 Aug 2001 12:06:23 -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: Michael Robinson Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? References: <200108110115.f7B1F4100321@netrinsics.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 Michael Robinson wrote: > > I'm currently trying to deal with the problem where malloc/free in a > signal handler will crash (in my case, the X window server) if a signal > arrives during malloc or free. The manual pages suck, since this should be under signal(3), not as a reference to sigaction(2), but... man 2 sigaction You can not allocate or free in signal handlers because malloc(3) and free(3) use brk(2) and sbrk(2), which are system calls that can't be used in a signal handler, since they are missing from the list of permitted function. Signals are pretty brain damaged anyway: the correct way to deal with them is to set a flag, and then handle them in the main event loop by checking the flag. NB: ANSI C requires you to mark this flag as "volatile", even though all externally referenced variables from signal handlers should be implicitly volatile, so that it doesn't optimize it into a register on you, and make your code not work. It's really not that hard to clean up the code... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 12:20:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 7B73037B403 for ; Sat, 11 Aug 2001 12:20:40 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 11068 invoked by uid 1000); 11 Aug 2001 19:19:24 -0000 Date: Sat, 11 Aug 2001 22:19:24 +0300 From: Peter Pentchev To: brian o'shea Cc: Raymond Wiker , les@safety.net, Rob , "hackers@FreeBSD.ORG" Subject: Re: the =+ operator Message-ID: <20010811221924.C1848@ringworld.oblivion.bg> Mail-Followup-To: brian o'shea , Raymond Wiker , les@safety.net, Rob , "hackers@FreeBSD.ORG" References: <3B73F0BC.548D40B3@home.com> <200108101446.HAA99867@safety.net> <15220.9386.441669.962830@raw.grenland.fast.no> <20010810154630.A27553@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010810154630.A27553@netapp.com>; from boshea@netapp.com on Fri, Aug 10, 2001 at 03:46: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 On Fri, Aug 10, 2001 at 03:46:30PM -0700, brian o'shea wrote: > On Fri, Aug 10, 2001 at 08:15:06PM +0200, Raymond Wiker wrote: > > > > This is actually wrong - the += and -= operators were > > originally written as =+ and =-. This is obviously ambiguous, given > > the fact that whitespace is ignored. > > Why does this have to be ambiguous? Your largest-possible-token sounds like a good and quite possibly correct idea, but your example is mightily wrong :) > Consider this: > > int o = 2; > int *p = &o; > int q = 8; > int r; > > r = q/*p /* comment */; > > printf("r == %d\n", r); > > > Is this equivalent to the following: > > r = q / *p; > > > Or is it equivalent to this: > > r = q /* p /* comment */ ; > > > C disambiguates between these two possible interpretations by matching > the largest possible token. I don't really think so. C disambiguates between these two possible interpretations by doing at least two passes over the code. Comments are weeded out by the C preprocessor, which jumps in at the first /*, and replaces everything until the first */ with whitespace. The compiler does not have to deal with the */ ambiguity at all, since it never sees the /*. > Thus, it is taken to be equivalent to: > > r = q; No, it's not. /* cannot be used in this way, it *is* taken to mean a comment by the preprocessor, and it produces weird mistakes. See for yourself: try to compile the following program: int main(void) { int p, *q; p = 2; q = &p; p = p /* q; /* comment */ } At least here, this is what happens: [roam@ringworld:v6 ~/c/misc/foo]$ cc -o foo10 foo10.c foo10.c: In function `main': foo10.c:8: syntax error before `}' [roam@ringworld:v6 ~/c/misc/foo]$ That is, the preprocessor has taken the whole of /* q; /* comment */ to be a comment, and has turned the program into: int main(void) { int p, *q; p = 2; q = &p; p = p } ..which is obviously wrong - no semicolon after the p = p statement. > In other words, these two lines are not equivalent: > > r = q/*p /* comment */; > > r = q/ *p /* comment */; > > > So, the =+ operator could be interprited correctly as long as it is the > largest possible token. It does leave more of an opportunity for human > misinterpritation, while my example is less likely to be seen. Once again, yes, the largest-possible-token is a good idea, and possibly implemented that way in most lex or flex-based parsers, but you picked a poor example to illustrate it :) G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 13:52: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from yoda.bmi.net (yoda.bmi.net [204.57.191.163]) by hub.freebsd.org (Postfix) with ESMTP id 56D5037B408 for ; Sat, 11 Aug 2001 13:52:02 -0700 (PDT) (envelope-from jmcoopr@webmail.bmi.net) Received: from johncoop.MSHOME (drumheller-router.bmi.net [206.63.201.3] (may be forged)) by yoda.bmi.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA27059; Sat, 11 Aug 2001 14:17:01 -0700 Received: from johncoop.MSHOME (localhost [127.0.0.1]) by johncoop.MSHOME (8.11.5/8.11.5) with ESMTP id f7BJJ8W54102; Sat, 11 Aug 2001 12:19:08 -0700 (PDT) (envelope-from jmcoopr@webmail.bmi.net) Date: Sat, 11 Aug 2001 12:18:57 -0700 From: John Merryweather Cooper To: tlambert2@mindspring.com Cc: Rob , "hackers @ FreeBSD . ORG" Subject: Re: the =+ operator Message-ID: <20010811121857.A41578@johncoop> References: <3B73F0BC.548D40B3@home.com> <3B757D14.B344931@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <3B757D14.B344931@mindspring.com>; from tlambert2@mindspring.com on Sat, Aug 11, 2001 at 11:44:36 -0700 X-Mailer: Balsa 1.1.7 Lines: 117 Sender: owner-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 2001.08.11 11:44 Terry Lambert wrote: > Rob wrote: > > I've searched far and wide on search engines to find out what the =+ > > operator does, to no avail. I'm porting some old code and found it. I > > made a test program and compiled it with gcc, and all it appears to do > > is the same as regular assignment. But I'm wondering if in some day > > long ago, it mean't something else? Thanks, Rob. > > Before ANSI went and ruined everything (e.g. by adding prototypes > instead of making the object file format store attribution data, > and smarter linkers, because the committee was packed with compiler > vendors who wanted to do good on benchmarks), there was K&R C. > Since when does any self-respecting compiler dictate object format? It's brain-damage for a compiler to screw with the object format--so much for inter-language linkage. Prototypes are an overwhelmingly "Good Thing(tm)" as behind-your-back implicit parameter conversion is death to serious numerical work. At least now, some control can be exercised over parameter conversions . . . > In K&R C, the one true C, token gathering was two pass; it did not > ingnore whitespace for token seperation on the first pass, and > ignored it on the second, when necessary to disambiguate unknown > tokens. > Two-pass lexing is also brain-damage. How to easily double compile time is a single step. If applied to C++, we'd wait night and day for the compile of just one port. :) Also, languages that are deliberately ambiguous are maintenance nightmeres--maintenance perfers a language that is 100% deterministic. Same way with porting. They're enough side effects to C compilers on different platforms already without creating MORE opportunities for subtle differences. > Historically, the =+ and =- operators were used in the original > C compilers... I believe this was for weenies who were unfortunate > enough to own HP calculators, but it was an anacronism even 1978, > which is when my copy of "The C Programming Language" book was > published (unfortunately, it's not a first printing); this is > noted on page 212, where they also talk about no "=" initializers > ("int i 1;" instead of "int i = 1;"; newer, dumber, compilers > have a hard time disambiguating expressions like "int i (17+BOO);" > from functions because of the one pass tokenizer, so this is not > allowed by ANSI, either). > To paraphrase Gen. George S. Patton: "The HP Calculator--the Greatest, Most Perfect(tm) Calculating-Implement devised . . . " :) Seriously, my understanding from K & R is that the C designers just thought it would be a "nice feature" to allow both versions of the operators. "Nice feature" is usually a synonymn for brain-damage in a compiler. :) > I have used many compilers that took "=-", "=+", "=/", "=*", "=>>", > etc., etc.. > > ANSI broke all this code when it stated that whitespace was always > ignored (thus permitting compiler writers to do single pass token > gathering using the "greedy" rule, which could be done with a > single pass LALR parser, spitting out tokens when the next character > could not possibly be part of the previous token). > And that is as it should be . . . Lexing to be fast needs to be single-pass. The same could be said for parsing. The agony over designing a truly "standard" C++ compiler (not a single example of which exists) should lay this out clearly . . . > I have also seen the "/\" (max), "\/" (min), and "^^" (McCarthy XOR, > moral symmetry for the McCarthy "||", "&&" operators), since the > compilers that used them could put them into single machine > instructions). > > My Manx Aztec C compiler for the IBM PC supports "=+" and "=-"; > it is also smart enought to turn: "x * 10" into "x <<=2; x++; x<<=1", > and the 68000 version was smart enough to realize the bus was 16 > bits, not 32 bits, and so made "int" 16 bits on the 68000, but 32 > bits on the 68k processors with 32 bit busses, resulting in single > cycle transfer times for the data: most other compilers, (e.g. > Lattice C), were stupid, and made int 32 bits to appease lousy > programmers. > As a long time user of Lattice C, your comment about 32 bit int's is inaccurate. This behaviour existed on Lattice C 6.04 only if you set a compiler switch to force it. Otherwise, int's were 16 bit. Lattice C also was not stupid--for it's time it was one of the best optimizing compilers on the market--bar none. It's sad that MacroHard all but put them out of business--and ironic considering Lattice made the first few interations of M$ C (1-4) for MacroHard. But then BG doesn't stand for one iota of competition, and never gave/gives a damn about technical product quality . . . > Something to think about, for you "style" wonks who insist on > "if ((a+=5))" instead of "if( a += 5)", not realizing that butting > up the parenthesis left associatively is required to make some > compilers work right, and the doubled parenthesis are just an > editorial comment by the compiler writers about their preferred > style of doing the test after the operation ("a += 5; if(a)"), > coming from being assembly weenies, and not really something > wrong, when they bitch about assignments in comparison statements. > "Style" is the essense of the best programming. Good programmers have it, the rest suffer for want of it . . . jmc =================== > Kids these days: change the programmer to fit the machine... > > -- 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 Sat Aug 11 14: 7: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 E829E37B409; Sat, 11 Aug 2001 14:07:38 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B255E81D06; Sat, 11 Aug 2001 16:07:28 -0500 (CDT) Date: Sat, 11 Aug 2001 16:07:28 -0500 From: Alfred Perlstein To: Terry Lambert Cc: Michael Robinson , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? Message-ID: <20010811160728.U85642@elvis.mu.org> References: <200108110115.f7B1F4100321@netrinsics.com> <3B75822F.E84799BD@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B75822F.E84799BD@mindspring.com>; from tlambert2@mindspring.com on Sat, Aug 11, 2001 at 12:06:23PM -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 * Terry Lambert [010811 14:06] wrote: > Michael Robinson wrote: > > > > I'm currently trying to deal with the problem where malloc/free in a > > signal handler will crash (in my case, the X window server) if a signal > > arrives during malloc or free. > > The manual pages suck, since this should be under signal(3), not > as a reference to sigaction(2), but... > > man 2 sigaction > > You can not allocate or free in signal handlers because malloc(3) > and free(3) use brk(2) and sbrk(2), which are system calls that > can't be used in a signal handler, since they are missing from > the list of permitted function. It's really the fact that malloc/free are not re-entrant that causes the problem. brk/sbrk by itself should be safe to call from a signal handler as they are syscalls and don't really share state with the process context in userland. -- -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 Sat Aug 11 14:16:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 7423537B409; Sat, 11 Aug 2001 14:16:25 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15Vg7g-000GcU-00; Sat, 11 Aug 2001 23:16:44 +0200 From: Sheldon Hearn To: tlambert2@mindspring.com Cc: Michael Robinson , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? In-reply-to: Your message of "Sat, 11 Aug 2001 12:06:23 MST." <3B75822F.E84799BD@mindspring.com> Date: Sat, 11 Aug 2001 23:16:44 +0200 Message-ID: <63889.997564604@axl.seasidesoftware.co.za> Sender: owner-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, 11 Aug 2001 12:06:23 MST, Terry Lambert wrote: > The manual pages suck, since this should be under signal(3), not > as a reference to sigaction(2), but... > > man 2 sigaction Some of us are so committed to improving the FreeBSD manual pages that we even try to get something positive out of this kind of negative bait from people who just bitch from the sidelines. What should we do to improve on the situation? We've already got this in signal(3): See sigaction(2) for a list of functions that are considered safe for use in signal handler. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 16:19: 7 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 656A437B405 for ; Sat, 11 Aug 2001 16:19:05 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7BNJ2020598; Sat, 11 Aug 2001 16:19:02 -0700 (PDT) (envelope-from dillon) Date: Sat, 11 Aug 2001 16:19:02 -0700 (PDT) From: Matt Dillon Message-Id: <200108112319.f7BNJ2020598@earth.backplane.com> To: John Merryweather Cooper Cc: tlambert2@mindspring.com, Rob , "hackers @ FreeBSD . ORG" Subject: Re: the =+ operator References: <3B73F0BC.548D40B3@home.com> <3B757D14.B344931@mindspring.com> <20010811121857.A41578@johncoop> Sender: owner-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 I was writing DICE I spent a whole 5 seconds considering the merits of the old =-, =+, etc... notation. Because that's all it took for me to come to the obvious conclusion that the old style notation was a pile of crap that only made everyone's lives more difficult - not just the poor sod (that's me) writing the compiler, but also the programmers, reviewers, and testers as well. The whole process of writing and testing code was positively impacted when those old style notations became illegal. And, for the record, the whitespace-ignoring bit has nothing to do with the lexing/parsing issue. Nothing at all whatsoever to do with it. Even in a modern compiler a construct like "+ =" is illegal. Whitespace is not ignored, it was simply clarified. The real problem with the old stuff was always human readability, debuggability, and lack of robustness. And... DICE still has the fastest one-pass lexer/parser on the planet. I just had to throw that in there :-) Too bad it only generates 68000 output. :"Style" is the essense of the best programming. Good programmers have it, :the rest suffer for want of it . . . : :jmc ... Amen. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 16:48:16 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 703ED37B409; Sat, 11 Aug 2001 16:48:10 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.137.15.Dial1.SanJose1.Level3.net [209.245.137.15]) by snipe.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id QAA12765; Sat, 11 Aug 2001 16:48:02 -0700 (PDT) Message-ID: <3B75C45B.1C8A37BA@mindspring.com> Date: Sat, 11 Aug 2001 16:48:43 -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: Sheldon Hearn Cc: Michael Robinson , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? References: <63889.997564604@axl.seasidesoftware.co.za> 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 Sheldon Hearn wrote: > > The manual pages suck, since this should be under signal(3), not > > as a reference to sigaction(2), but... > > > > man 2 sigaction > > Some of us are so committed to improving the FreeBSD manual pages that > we even try to get something positive out of this kind of negative bait > from people who just bitch from the sidelines. > > What should we do to improve on the situation? We've already got this > in signal(3): > > See sigaction(2) for a list of functions that are considered safe for > use in signal handler. Ultimately, you'd really want the signal handler to complain when it's called by putting the whole OS into a "pedantic" mode for testing purposes (i.e.: it complains abaout the calls when they happen). This _could_ be done with shared libraries with state flags, and alternate shared library paths, but ldconfig is a barrier these days... he could have gotten the same data with a "why is this broken?" command that switched out his libraries on him, and a flag that was set when in the trampoline, and not set outside the trampoline. As for man pages, I did the manual page corrections for a couple of things, including one or two of the AIO pages, but it's really going to need a real audit. The work to do is in paraphrasing the Go SOLO 2 CDROM man pages, without violating the copyright. Really, we need some college English departments involved in having people work on this for technical writing class credit; Linux seems to have no problem attracting non-programmers... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 16:55:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 33EE037B407; Sat, 11 Aug 2001 16:55:50 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15VicT-000HHY-00; Sun, 12 Aug 2001 01:56:41 +0200 From: Sheldon Hearn To: tlambert2@mindspring.com Cc: Michael Robinson , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? In-reply-to: Your message of "Sat, 11 Aug 2001 16:48:43 MST." <3B75C45B.1C8A37BA@mindspring.com> Date: Sun, 12 Aug 2001 01:56:41 +0200 Message-ID: <66435.997574201@axl.seasidesoftware.co.za> Sender: owner-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, 11 Aug 2001 16:48:43 MST, Terry Lambert wrote: > The work to do is in paraphrasing the Go SOLO 2 CDROM man pages, > without violating the copyright. > > Really, we need some college English departments involved in > having people work on this for technical writing class credit; > Linux seems to have no problem attracting non-programmers... Well, as long as you insist on keeping the problem description to yourself, the vast hordes of non-programmers at our disposal can't help much, now can they? Sometimes, I really wish you'd deliver useful criticism instead of just sounding impressive. I'm sure there's merit behind what you're saying, but you're really not helping until you start pointing to a specific problem. Ciao, Sheldon. PS: Perhaps 'Go SOLO 2 CDROM' means something that puts your comments completely into perspective. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 17: 5: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from d1c47d61.gw206.dsl.airmail.net (d1c47d61.gw206.dsl.airmail.net [209.196.125.97]) by hub.freebsd.org (Postfix) with ESMTP id 4CC6D37B403 for ; Sat, 11 Aug 2001 17:05:00 -0700 (PDT) (envelope-from wardd@d1c47d61.gw206.dsl.airmail.net) Received: (from wardd@localhost) by d1c47d61.gw206.dsl.airmail.net (8.11.4/8.11.1) id f7BJKta00690 for hackers@freebsd.org; Sat, 11 Aug 2001 19:20:55 GMT (envelope-from wardd) Date: Sat, 11 Aug 2001 19:20:54 +0000 From: William Ward To: hackers@freebsd.org Subject: natd and aliases on same interface Message-ID: <20010811192054.A669@d1c47d61.gw206.dsl.airmail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 How can I tell natd not to divert an alias when trying to communicate on my local area network? I'm sure this is a common problem so I won't go into too much detail. I have four machines connected to the ports on my DSL router. I'm using one machine with nat to connect the other three machines to the internet. The problem is caused because I have two subnets on the same interface and nat translates the alias to the public IP address before going out over the local area network. This is what I would like to avoid: toaster% telnet 10.0.0.25 ... sawdust% who am i wardd ttyp2 Nov 22 07:33 (128.1.1.2) ^^^^^^^^^ this! I would much rather the other box see the 10.x address instead. d1c47d61# ifconfig dc0 dc0: flags=8843 mtu 1500 inet 128.1.1.2 netmask 0xffffffc0 broadcast 128.1.1.0 inet6 XXXX::XXX:XXXX:XXXX:XXXX%dc0 prefixlen 64 scopeid 0x1 inet 10.0.0.11 netmask 0xffffff00 broadcast 10.0.0.255 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect (100baseTX) status: active d1c47d61# ipfw list 00050 divert 8668 ip from any to any via dc0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 65000 allow ip from any to any 65535 deny ip from any to any The machine is running 4.3-CURRENT. /William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 17:25:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 7674B37B403; Sat, 11 Aug 2001 17:25:06 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.137.15.Dial1.SanJose1.Level3.net [209.245.137.15]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA18351; Sat, 11 Aug 2001 17:25:01 -0700 (PDT) Message-ID: <3B75CD06.7E7BA39F@mindspring.com> Date: Sat, 11 Aug 2001 17:25: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: Sheldon Hearn Cc: Michael Robinson , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? References: <66435.997574201@axl.seasidesoftware.co.za> 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 Sheldon Hearn wrote: > Well, as long as you insist on keeping the problem description to > yourself, the vast hordes of non-programmers at our disposal can't help > much, now can they? But I don't. All you need to do is: 1) Buy a copy of the "Go SOLO 2" book. 2) Read the man pages on the included CDROM side by side with the FreeBSD man pages for the same command. 3) Correct the FreeBSD man pages: a) When they are not as verbose, make them more verbose (case in point) b) When they are different, ask which behaviour is correct for FreeBSD i) Correct the man pages, if FreeBSD matches "Go SOLO 2" ii) Correct the man pages, if FreeBSD does not match "Go SOLO 2", and add an entry to the bugs section iii) Add modified man pages for FreeBSD, and add a comment for future man page editors about the difference being intentional, if FreeBSD has decided on gratuitous incompatability While 3)b)ii rewuires a post to a mailing list and a wait for an answer, and 3)b)iii requires the same, where the answer ends up actually being a policy decision, the rest of them are really no-brainers. > Sometimes, I really wish you'd deliver useful criticism instead of just > sounding impressive. I'm sure there's merit behind what you're saying, > but you're really not helping until you start pointing to a specific > problem. I think that the fact that this person looked at the manual page, and missed _the last line_, and then asked the question, in the context of not knowing that IF they knew how malloc was implemented, and IF they had dereferenced the seemingly least important part of the manual page (by way of organization), they would have been able to find the answer. It's like trying to find something in hierachically organized "GNU info" documentation: redundancy is useful, and try to find "__PRETTY_FUNCTION__" in the "gcc" documentation, when you need to read the man page carefully to find the "info" reference, and then need to run the "info" program instead to find the "real" documentation, and then either know emacs, or linearly tree search through 37 documents (yes, I counted), to find something that should be on the "cpp" man page. > PS: Perhaps 'Go SOLO 2 CDROM' means something that puts your comments > completely into perspective. Yes. It contains all of the POSIX/Single UNIX Specification manual pages, in HTML format, on CDROM: Go SOLO 2 "The Authorized Guide to Version 2 of the Single UNIX Specification" Editor Andrew Josey The Open Group; X/Open, OSF ISBN 0-13-575689-8 US$89.00 Yes, it's expensive; I'm sure it's still expensive on Amazon, though less so. Since FreeBSD has adopted POSIX as its measure of standards compliance (e.g. SVR4 signal restart behavior, SVR4 process group revocation, etc.), it is the gold standard. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 17:48:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 7213D37B406; Sat, 11 Aug 2001 17:48:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.137.15.Dial1.SanJose1.Level3.net [209.245.137.15]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA27999; Sat, 11 Aug 2001 17:48:28 -0700 (PDT) Message-ID: <3B75D285.B8813EA1@mindspring.com> Date: Sat, 11 Aug 2001 17:49:09 -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: Sheldon Hearn , Michael Robinson , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? References: <66435.997574201@axl.seasidesoftware.co.za> <3B75CD06.7E7BA39F@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Sheldon Hearn wrote: > > Well, as long as you insist on keeping the problem description to > > yourself, the vast hordes of non-programmers at our disposal can't help > > much, now can they? > > But I don't. > > All you need to do is: > > 1) Buy a copy of the "Go SOLO 2" book. > 2) Read the man pages on the included CDROM side by side > with the FreeBSD man pages for the same command. > 3) Correct the FreeBSD man pages: > a) When they are not as verbose, make them more > verbose (case in point) > b) When they are different, ask which behaviour > is correct for FreeBSD > i) Correct the man pages, if FreeBSD > matches "Go SOLO 2" > ii) Correct the man pages, if FreeBSD > does not match "Go SOLO 2", and add > an entry to the bugs section > iii) Add modified man pages for FreeBSD, > and add a comment for future man > page editors about the difference > being intentional, if FreeBSD has > decided on gratuitous incompatability To add to this, I am willing to put up to US$1000 where my mouth is: If you are an experienced technical writer, or you are a an English major, and can provide your bonifides, and will commit to making at least 10 man page corrections as a result, I will buy you a copy of the "Go SOLO 2" book and ship it to you. I will do this for 10 people, and I will give preference to people with FreeBSD commit priv's to the documentation tree. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 17:58:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id DED5137B403; Sat, 11 Aug 2001 17:58:41 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15VjbV-000HVe-00; Sun, 12 Aug 2001 02:59:45 +0200 From: Sheldon Hearn To: tlambert2@mindspring.com Cc: Michael Robinson , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? In-reply-to: Your message of "Sat, 11 Aug 2001 17:49:09 MST." <3B75D285.B8813EA1@mindspring.com> Date: Sun, 12 Aug 2001 02:59:45 +0200 Message-ID: <67309.997577985@axl.seasidesoftware.co.za> Sender: owner-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, 11 Aug 2001 17:49:09 MST, Terry Lambert wrote: > If you are an experienced technical writer, or you are a an > English major, and can provide your bonifides I don't have the certifications that you think are required. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 11 18: 4: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id AAAE737B408; Sat, 11 Aug 2001 18:04:02 -0700 (PDT) (envelope-from freebsd-ml@econos.de) Received: from stefan-bt (pD95024D4.dip.t-dialin.net [217.80.36.212]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id DAA24969; Sun, 12 Aug 2001 03:04:01 +0200 (MET DST) From: Stefan Hoffmeister To: hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? Date: Sun, 12 Aug 2001 03:03:42 +0200 Organization: Econos Message-ID: References: <66435.997574201@axl.seasidesoftware.co.za> <3B75CD06.7E7BA39F@mindspring.com> In-Reply-To: <3B75CD06.7E7BA39F@mindspring.com> X-Mailer: Forte Agent 1.8/32.548 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 [Trimmed CC list to only include the mailing lists] : On Sat, 11 Aug 2001 17:25:42 -0700, Terry Lambert wrote: >1) Buy a copy of the "Go SOLO 2" book. ... >It contains all of the POSIX/Single UNIX Specification >manual pages, in HTML format, on CDROM: FWIW, I personally like http://www.unix-systems.org/online.html At one stage, I got a tarball of HTML docs (after registering?) and live off that whenever I run into all too often inadequate documentation. If you go to http://www.opengroup.org/austin/ and register with them, you can download a couple of MBs that contain the (final draft of the) work of the Austin Group: The Austin Common Standards Revision Group (CSRG) is a joint technical working group established to consider the matter of a common revision of ISO/IEC 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2 and the appropriate parts of the Single UNIX Specification. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message