From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 00:30:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBFE437B401; Sun, 20 Apr 2003 00:30:51 -0700 (PDT) Received: from demos.su (mx.demos.su [194.87.0.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id E123343FD7; Sun, 20 Apr 2003 00:30:49 -0700 (PDT) (envelope-from mitya@fling-wing.demos.su) Received: from [194.87.5.69] (HELO fling-wing.demos.su) by demos.su (CommuniGate Pro SMTP 4.0.6/D4) with ESMTP-TLS id 67648376; Sun, 20 Apr 2003 11:30:48 +0400 Received: from fling-wing.demos.su (localhost [127.0.0.1]) by fling-wing.demos.su (8.12.9/8.12.6) with ESMTP id h3K7UmAu065610; Sun, 20 Apr 2003 11:30:48 +0400 (MSD) (envelope-from mitya@fling-wing.demos.su) Received: (from mitya@localhost) by fling-wing.demos.su (8.12.9/8.12.6/Submit) id h3K7UmOJ065609; Sun, 20 Apr 2003 11:30:48 +0400 (MSD) Date: Sun, 20 Apr 2003 11:30:47 +0400 From: Dmitry Sivachenko To: Don Lewis Message-ID: <20030420073047.GA64397@fling-wing.demos.su> References: <200304192156.h3JLuDXB019980@gw.catspoiler.org> <200304192215.h3JMFKXB020012@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200304192215.h3JMFKXB020012@gw.catspoiler.org> WWW-Home-Page: http://mitya.pp.ru/ X-PGP-Key: http://mitya.pp.ru/mitya.asc User-Agent: Mutt/1.5.4i cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 07:30:52 -0000 On Sat, Apr 19, 2003 at 03:15:20PM -0700, Don Lewis wrote: > Dmitry, > > If you still have the core and kernel files, I'd appreciate it if you > could point gdb at them and print the following stuff from the malloc() > stack frame. > > indx > &bucket[0] > kbp > *kpb > allocsize > npg > cp > freep > *freep > va > In backtrace I posted malloc was called twice. Since I am not sure which one you are interested in, I am sending these values for both. (kgdb) up 6 #6 0xc015daff in malloc (size=128, type=0xc02aca60, flags=2) at /mnt/se3/releng_4/src/sys/kern/kern_malloc.c:243 243 va = kbp->kb_next; (kgdb) p indx $1 = 7 (kgdb) p &bucket[0] $2 = (struct kmembuckets *) 0xc02bcee0 (kgdb) p kbp $3 = (struct kmembuckets *) 0x5cdd8000 (kgdb) p *kpb No symbol "kpb" in current context. (kgdb) p *kbp Cannot access memory at address 0x5cdd8000. (kgdb) p allocsize $4 = -730301488 (kgdb) p npg $5 = 0 (kgdb) p cp $6 = 0x0 (kgdb) p freep $7 = (struct freelist *) 0x0 (kgdb) p va $8 = 0x5cdd8000
(kgdb) (kgdb) up 16 #22 0xc015daff in malloc (size=72, type=0xc029fee0, flags=0) at /mnt/se3/releng_4/src/sys/kern/kern_malloc.c:243 243 va = kbp->kb_next; (kgdb) p indx $9 = 7 (kgdb) p &bucket[0] $10 = (struct kmembuckets *) 0xc02bcee0 (kgdb) p kbp $11 = (struct kmembuckets *) 0x5cdd8000 (kgdb) p *kbp Cannot access memory at address 0x5cdd8000. (kgdb) p allocsize $12 = -349729108 (kgdb) p npg $13 = 0 (kgdb) p cp $14 = 0x0 (kgdb) p freep $15 = (struct freelist *) 0x0 (kgdb) p va $16 = 0x5cdd8000
From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 01:16:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9456D37B401 for ; Sun, 20 Apr 2003 01:16:29 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B161943F85 for ; Sun, 20 Apr 2003 01:16:28 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3K8GGXB020865; Sun, 20 Apr 2003 01:16:20 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304200816.h3K8GGXB020865@gw.catspoiler.org> Date: Sun, 20 Apr 2003 01:16:16 -0700 (PDT) From: Don Lewis To: mitya@cavia.pp.ru In-Reply-To: <20030420073047.GA64397@fling-wing.demos.su> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 08:16:29 -0000 On 20 Apr, Dmitry Sivachenko wrote: > On Sat, Apr 19, 2003 at 03:15:20PM -0700, Don Lewis wrote: >> Dmitry, >> >> If you still have the core and kernel files, I'd appreciate it if you >> could point gdb at them and print the following stuff from the malloc() >> stack frame. >> >> indx >> &bucket[0] >> kbp >> *kpb >> allocsize >> npg >> cp >> freep >> *freep >> va >> > > In backtrace I posted malloc was called twice. Since I am not sure > which one you are interested in, I am sending these values for both. The second one, which is where the first trap occurred. > (kgdb) up 6 > #6 0xc015daff in malloc (size=128, type=0xc02aca60, flags=2) > at /mnt/se3/releng_4/src/sys/kern/kern_malloc.c:243 > 243 va = kbp->kb_next; > (kgdb) p indx > $1 = 7 > (kgdb) p &bucket[0] > $2 = (struct kmembuckets *) 0xc02bcee0 > (kgdb) p kbp > $3 = (struct kmembuckets *) 0x5cdd8000 > (kgdb) p *kpb > No symbol "kpb" in current context. > (kgdb) p *kbp > Cannot access memory at address 0x5cdd8000. > (kgdb) p allocsize > $4 = -730301488 > (kgdb) p npg > $5 = 0 > (kgdb) p cp > $6 = 0x0 > (kgdb) p freep > $7 = (struct freelist *) 0x0 > (kgdb) p va > $8 = 0x5cdd8000
> (kgdb) > > > (kgdb) up 16 > #22 0xc015daff in malloc (size=72, type=0xc029fee0, flags=0) > at /mnt/se3/releng_4/src/sys/kern/kern_malloc.c:243 > 243 va = kbp->kb_next; > (kgdb) p indx > $9 = 7 > (kgdb) p &bucket[0] > $10 = (struct kmembuckets *) 0xc02bcee0 > (kgdb) p kbp > $11 = (struct kmembuckets *) 0x5cdd8000 That's not good ... if index is 7, and sizeof struct kmembuckets is 36, I believe that kbp = &bucket[indx]; should assign 0xc02bcfdc to kbp. It looks like kbp might be getting stomped on somehow. > (kgdb) p *kbp > Cannot access memory at address 0x5cdd8000. Yeah, kbp is pointing at a non-existent memory location. > (kgdb) p allocsize > $12 = -349729108 > (kgdb) p npg > $13 = 0 Since allocsize is is garbage that doesn't show any relationship to size, and since npg isn't consistent with either size of allocsize, it looks to me like kbp->kb_next is initially non-NULL, so we're not executing the "if" block. if (kbp->kb_next == NULL) { kbp->kb_last = NULL; if (size > MAXALLOCSAVE) allocsize = roundup(size, PAGE_SIZE); else allocsize = 1 << indx; npg = btoc(allocsize); va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg), flags ); The other possibility is that these are also getting smashed somehow. > (kgdb) p cp > $14 = 0x0 > (kgdb) p freep > $15 = (struct freelist *) 0x0 If we don't get into the "if" block, these will contain leftover garbages from the stack. > (kgdb) p va > $16 = 0x5cdd8000
Interesting ... how does va get the same value as kbp? Is it coming from the va = (caddr_t) kmem_malloc() assignment in the "if" block that we don't think we're executing, or the va = kbp->kb_next; assignment that is causing the panic? If kbp is pointing to a non-existent page, why does Terry's patch seem to fix the problem for you? I wonder if things are getting further munged after the trap occurs? That would make it more difficult to track down the problem from the core file. Something else of interest to print is bucket[7] bucket[7].kb_next and bucket[7].kb_last might shed some light. Something interesting is that the fault address, and the values of va and kbp are the same in both stack frames ... One other question ... is your kernel compiled with INVARIANTS? That changes the definition of struct freelist. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 02:36:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBB1137B401; Sun, 20 Apr 2003 02:36:32 -0700 (PDT) Received: from demos.su (mx.demos.su [194.87.0.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E96843F75; Sun, 20 Apr 2003 02:36:31 -0700 (PDT) (envelope-from mitya@fling-wing.demos.su) Received: from [194.87.5.69] (HELO fling-wing.demos.su) by demos.su (CommuniGate Pro SMTP 4.0.6/D4) with ESMTP-TLS id 67653534; Sun, 20 Apr 2003 13:36:29 +0400 Received: from fling-wing.demos.su (localhost [127.0.0.1]) by fling-wing.demos.su (8.12.9/8.12.6) with ESMTP id h3K9aTAu078075; Sun, 20 Apr 2003 13:36:29 +0400 (MSD) (envelope-from mitya@fling-wing.demos.su) Received: (from mitya@localhost) by fling-wing.demos.su (8.12.9/8.12.6/Submit) id h3K9aS3v078074; Sun, 20 Apr 2003 13:36:28 +0400 (MSD) Date: Sun, 20 Apr 2003 13:36:28 +0400 From: Dmitry Sivachenko To: Don Lewis Message-ID: <20030420093628.GA76333@fling-wing.demos.su> References: <20030420073047.GA64397@fling-wing.demos.su> <200304200816.h3K8GGXB020865@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200304200816.h3K8GGXB020865@gw.catspoiler.org> WWW-Home-Page: http://mitya.pp.ru/ X-PGP-Key: http://mitya.pp.ru/mitya.asc User-Agent: Mutt/1.5.4i cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 09:36:33 -0000 On Sun, Apr 20, 2003 at 01:16:16AM -0700, Don Lewis wrote: > On 20 Apr, Dmitry Sivachenko wrote: > > On Sat, Apr 19, 2003 at 03:15:20PM -0700, Don Lewis wrote: > If we don't get into the "if" block, these will contain leftover > garbages from the stack. > > > (kgdb) p va > > $16 = 0x5cdd8000
> > Interesting ... how does va get the same value as kbp? Is it coming > from the > va = (caddr_t) kmem_malloc() > assignment in the "if" block that we don't think we're executing, or the > va = kbp->kb_next; > assignment that is causing the panic? > > If kbp is pointing to a non-existent page, why does Terry's patch seem > to fix the problem for you? Well, here is probably a misunderstanding.. We did NOT apply Terry's patch. Let me quote a bit from my e-mail to Terry: TL> Did my patch fix your problem? TL> TL> Or did you tune your kernel, as I suggested, to fix your problem? TL> TL> Or is it still a problem? DS>We changed maxusers from 512 to 0 and decreased the number of DS>NMBCLUSTERS. Now everything is working fine, but since these panics occured DS>about once a week I can't say for sure they are completely gone. DS>Let's wait at least one more week... Thus I wanted to say that we only tuned maxusers and NMBCLUSTERS. We run virgin -STABLE kernel without any patches. Probably my english leaves much to be desired ;-(( > > I wonder if things are getting further munged after the trap occurs? > That would make it more difficult to track down the problem from the > core file. > > Something else of interest to print is > bucket[7] > bucket[7].kb_next and bucket[7].kb_last might shed some light. > (kgdb) up 22 #22 0xc015daff in malloc (size=72, type=0xc029fee0, flags=0) at /mnt/se3/releng_4/src/sys/kern/kern_malloc.c:243 243 va = kbp->kb_next; (kgdb) p bucket[7] $1 = {kb_next = 0x5cdd8000
, kb_last = 0xc8fcb000 "", kb_calls = 2127276, kb_total = 4256, kb_elmpercl = 32, kb_totalfree = 1264, kb_highwat = 160, kb_couldfree = 5497} (kgdb) p bucket[7].kb_next $2 = 0x5cdd8000
(kgdb) p bucket[7].kb_last $3 = 0xc8fcb000 "" (kgdb) > > Something interesting is that the fault address, and the values of va > and kbp are the same in both stack frames ... > > > One other question ... is your kernel compiled with INVARIANTS? That > changes the definition of struct freelist. Without. PS: If you need additional information, feel free to ask. I am more than willing to help. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 03:18:15 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50C0837B401; Sun, 20 Apr 2003 03:18:14 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35C5443FCB; Sun, 20 Apr 2003 03:18:13 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3KAI5XB021318; Sun, 20 Apr 2003 03:18:09 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304201018.h3KAI5XB021318@gw.catspoiler.org> Date: Sun, 20 Apr 2003 03:18:05 -0700 (PDT) From: Don Lewis To: demon@FreeBSD.org In-Reply-To: <20030420093628.GA76333@fling-wing.demos.su> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 10:18:15 -0000 On 20 Apr, Dmitry Sivachenko wrote: > On Sun, Apr 20, 2003 at 01:16:16AM -0700, Don Lewis wrote: >> If kbp is pointing to a non-existent page, why does Terry's patch seem >> to fix the problem for you? > > Well, here is probably a misunderstanding.. > We did NOT apply Terry's patch. Let me quote a bit from my e-mail to Terry: > > TL> Did my patch fix your problem? > TL> > TL> Or did you tune your kernel, as I suggested, to fix your problem? > TL> > TL> Or is it still a problem? > > DS>We changed maxusers from 512 to 0 and decreased the number of > DS>NMBCLUSTERS. Now everything is working fine, but since these panics occured > DS>about once a week I can't say for sure they are completely gone. > DS>Let's wait at least one more week... > > Thus I wanted to say that we only tuned maxusers and NMBCLUSTERS. We > run virgin -STABLE kernel without any patches. Probably my english leaves much > to be desired ;-(( Your English seems just fine to me. I just got the impression from Terry that the patch is what fixed the problem for you. >> I wonder if things are getting further munged after the trap occurs? >> That would make it more difficult to track down the problem from the >> core file. >> >> Something else of interest to print is >> bucket[7] >> bucket[7].kb_next and bucket[7].kb_last might shed some light. >> > > (kgdb) up 22 > #22 0xc015daff in malloc (size=72, type=0xc029fee0, flags=0) > at /mnt/se3/releng_4/src/sys/kern/kern_malloc.c:243 > 243 va = kbp->kb_next; > (kgdb) p bucket[7] > $1 = {kb_next = 0x5cdd8000
, > kb_last = 0xc8fcb000 "", kb_calls = 2127276, kb_total = 4256, > kb_elmpercl = 32, kb_totalfree = 1264, kb_highwat = 160, kb_couldfree = 5497} > (kgdb) p bucket[7].kb_next > $2 = 0x5cdd8000
> (kgdb) p bucket[7].kb_last > $3 = 0xc8fcb000 "" > (kgdb) That explains a quite a bit. The free list is somehow getting corrupted. That's why the 0x5cdd8000 value shows up in both stack frames. The value of kb_last looks ok, though. Because kb_next is not NULL, we skip the "if" block that allocates more memory and proceed to line 243. Gdb is lying a bit though, the trap isn't happening on line 243, va is just getting the garbage value there. The trap is actually happening on the next line when we try to dereference this garbage pointer: kbp->kb_next = ((struct freelist *)va)->next; It sure would be nice to know the source of this wierd value. It's obviously not a pointer, but it's not obvious to me what it might be. It sure looks to me like something is writing to memory that has already been put back on the free list and is stomping on the next pointer in one of the memory blocks on the list. When this block gets allocated again, malloc() does: va = kbp->kb_next; kbp->kb_next = ((struct freelist *)va)->next; and stores the garbage in kb_next, where we trip over it on the next allocation. >> One other question ... is your kernel compiled with INVARIANTS? That >> changes the definition of struct freelist. > > Without. This could potentially be difficult to track down. Probably the best bet is to go back to the previous configuration and compile with INVARIANTS and hope that this will catch the problem a bit closer to the source. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 04:04:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AB3B37B401; Sun, 20 Apr 2003 04:04:46 -0700 (PDT) Received: from demos.su (mx.demos.su [194.87.0.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D0A43FCB; Sun, 20 Apr 2003 04:04:44 -0700 (PDT) (envelope-from mitya@fling-wing.demos.su) Received: from [194.87.5.69] (HELO fling-wing.demos.su) by demos.su (CommuniGate Pro SMTP 4.0.6/D4) with ESMTP-TLS id 67657348; Sun, 20 Apr 2003 15:04:43 +0400 Received: from fling-wing.demos.su (localhost [127.0.0.1]) by fling-wing.demos.su (8.12.9/8.12.6) with ESMTP id h3KB4gAu085400; Sun, 20 Apr 2003 15:04:42 +0400 (MSD) (envelope-from mitya@fling-wing.demos.su) Received: (from mitya@localhost) by fling-wing.demos.su (8.12.9/8.12.6/Submit) id h3KB4gBs085399; Sun, 20 Apr 2003 15:04:42 +0400 (MSD) Date: Sun, 20 Apr 2003 15:04:42 +0400 From: Dmitry Sivachenko To: Don Lewis Message-ID: <20030420110442.GA85172@fling-wing.demos.su> References: <20030420093628.GA76333@fling-wing.demos.su> <200304201018.h3KAI5XB021318@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200304201018.h3KAI5XB021318@gw.catspoiler.org> WWW-Home-Page: http://mitya.pp.ru/ X-PGP-Key: http://mitya.pp.ru/mitya.asc User-Agent: Mutt/1.5.4i cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 11:04:53 -0000 On Sun, Apr 20, 2003 at 03:18:05AM -0700, Don Lewis wrote: > On 20 Apr, Dmitry Sivachenko wrote: > > On Sun, Apr 20, 2003 at 01:16:16AM -0700, Don Lewis wrote: > > >> If kbp is pointing to a non-existent page, why does Terry's patch seem > >> to fix the problem for you? > > > > Well, here is probably a misunderstanding.. > > We did NOT apply Terry's patch. Let me quote a bit from my e-mail to Terry: > > > > TL> Did my patch fix your problem? > > TL> > > TL> Or did you tune your kernel, as I suggested, to fix your problem? > > TL> > > TL> Or is it still a problem? > > > > DS>We changed maxusers from 512 to 0 and decreased the number of > > DS>NMBCLUSTERS. Now everything is working fine, but since these panics occured > > DS>about once a week I can't say for sure they are completely gone. > > DS>Let's wait at least one more week... > > > > Thus I wanted to say that we only tuned maxusers and NMBCLUSTERS. We > > run virgin -STABLE kernel without any patches. Probably my english leaves much > > to be desired ;-(( > > Your English seems just fine to me. > > I just got the impression from Terry that the patch is what fixed the > problem for you. > > > >> I wonder if things are getting further munged after the trap occurs? > >> That would make it more difficult to track down the problem from the > >> core file. > >> > >> Something else of interest to print is > >> bucket[7] > >> bucket[7].kb_next and bucket[7].kb_last might shed some light. > >> > > > > (kgdb) up 22 > > #22 0xc015daff in malloc (size=72, type=0xc029fee0, flags=0) > > at /mnt/se3/releng_4/src/sys/kern/kern_malloc.c:243 > > 243 va = kbp->kb_next; > > (kgdb) p bucket[7] > > $1 = {kb_next = 0x5cdd8000
, > > kb_last = 0xc8fcb000 "", kb_calls = 2127276, kb_total = 4256, > > kb_elmpercl = 32, kb_totalfree = 1264, kb_highwat = 160, kb_couldfree = 5497} > > (kgdb) p bucket[7].kb_next > > $2 = 0x5cdd8000
> > (kgdb) p bucket[7].kb_last > > $3 = 0xc8fcb000 "" > > (kgdb) > > That explains a quite a bit. The free list is somehow getting > corrupted. That's why the 0x5cdd8000 value shows up in both stack > frames. The value of kb_last looks ok, though. Because kb_next is not > NULL, we skip the "if" block that allocates more memory and proceed to > line 243. Gdb is lying a bit though, the trap isn't happening on line > 243, va is just getting the garbage value there. The trap is actually > happening on the next line when we try to dereference this garbage > pointer: > kbp->kb_next = ((struct freelist *)va)->next; > > It sure would be nice to know the source of this wierd value. It's > obviously not a pointer, but it's not obvious to me what it might be. > > It sure looks to me like something is writing to memory that has already > been put back on the free list and is stomping on the next pointer in > one of the memory blocks on the list. When this block gets allocated > again, malloc() does: > va = kbp->kb_next; > kbp->kb_next = ((struct freelist *)va)->next; > and stores the garbage in kb_next, where we trip over it on the next > allocation. > > > >> One other question ... is your kernel compiled with INVARIANTS? That > >> changes the definition of struct freelist. > > > > Without. > > This could potentially be difficult to track down. Probably the best > bet is to go back to the previous configuration and compile with > INVARIANTS and hope that this will catch the problem a bit closer to the > source. > OK, I'll restore our previous configuration tomorrow and add INVARIANTS. I'll let you know when a fresh crash dump will be ready. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 04:38:07 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE89537B404 for ; Sun, 20 Apr 2003 04:38:05 -0700 (PDT) Received: from Danovitsch.dnsq.org (b74143.upc-b.chello.nl [212.83.74.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6B7743FB1 for ; Sun, 20 Apr 2003 04:38:03 -0700 (PDT) (envelope-from Danovitsch@Vitsch.net) Received: from FreeBSD.Danovitsch.LAN (b83007.upc-b.chello.nl [212.83.83.7]) by Danovitsch.dnsq.org (8.12.3p2/8.11.3) with ESMTP id h3KBX8Ca013186; Sun, 20 Apr 2003 13:33:09 +0200 (CEST) (envelope-from Danovitsch@Vitsch.net) Content-Type: text/plain; charset="iso-8859-1" From: "Daan Vreeken [PA4DAN]" To: rhett@alasir.com Date: Sun, 20 Apr 2003 13:39:51 +0200 User-Agent: KMail/1.4.3 References: <20030420021752.13758.qmail@web21509.mail.yahoo.com> In-Reply-To: <20030420021752.13758.qmail@web21509.mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200304201339.51145.Danovitsch@Vitsch.net> cc: FreeBSD-hackers@FreeBSD.org Subject: Re: low-level routines X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 11:38:07 -0000 On Sunday 20 April 2003 04:17, RMH wrote: > Hello gentlemen, > > could you point me to some function(s) used by FreeBSD to read\write va= lues > from\to hardware ports? I remember outp\inp (or outportb\inportb for > Borland Turbo C) from DOS times, but these of course don't work for UNI= X... To read/write io ports directly on FreeBSD, you need to open /dev/io After your process has successfully opened /dev/io you can read/write por= ts=20 with these pieces of inline-assembly : unsigned char inp(unsigned short Port) { unsigned char Data =3D 0; =20 __asm __volatile("inb %%dx,%0" : "=3Da" (Data) : "d" (Port) ); =20 return Data; } void outp(unsigned short Port, unsigned char Data) { unsigned char D =3D Data; =20 __asm __volatile("outb %0,%%dx" : : "a" (D), "d" (Port) ); } Here's a link to some code that I use to write to the parallel port direc= tly : http://danovitsch.dnsq.org/cgi-bin/gpl/cat.cgi/lampd/v1.0?lampd.c grtz, Daan From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 07:47:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 256F137B401 for ; Sun, 20 Apr 2003 07:47:41 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BBEDE43FD7 for ; Sun, 20 Apr 2003 07:47:39 -0700 (PDT) (envelope-from alexander.pohoyda@gmx.net) Received: (qmail 24080 invoked by uid 65534); 20 Apr 2003 14:47:38 -0000 Received: from p508BE949.dip.t-dialin.net (EHLO oak.pohoyda.family) (80.139.233.73) by mail.gmx.net (mp023-rz3) with SMTP; 20 Apr 2003 16:47:38 +0200 Received: from oak.pohoyda.family (oak.pohoyda.family [127.0.0.1]) by oak.pohoyda.family (8.12.8/8.12.6) with ESMTP id h3KElZfH003155; Sun, 20 Apr 2003 16:47:35 +0200 (CEST) (envelope-from alexander.pohoyda@gmx.net) Received: (from apog@localhost) by oak.pohoyda.family (8.12.8/8.12.6/Submit) id h3KElWGl003149; Sun, 20 Apr 2003 16:47:32 +0200 (CEST) (envelope-from alexander.pohoyda@gmx.net) X-Authentication-Warning: oak.pohoyda.family: apog set sender to alexander.pohoyda@gmx.net using -f Sender: alexander.pohoyda@gmx.net To: Martin Blapp References: <20030418132152.X6156@cvs.imp.ch> <20030420014419.T95995@cvs.imp.ch> From: Alexander Pohoyda Date: 20 Apr 2003 16:47:32 +0200 In-Reply-To: <20030420014419.T95995@cvs.imp.ch> Message-ID: <87n0il1b0b.fsf@oak.pohoyda.family> Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: hackers@freebsd.org Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 14:47:41 -0000 Martin Blapp writes: > I uploaded a fixed patch to the same URL as before. > http://people.freebsd.org/~mbr/patches/dhclient-interfacepolling.diff Might be a good idea to move a closing bracket outside of the ifdef: --- contrib/isc-dhcp.old/client/dhclient.c +++ contrib/isc-dhcp/client/dhclient.c @@ -3134... @@ return (0); -} #else /* ifdef __FreeBSD__ */ return (1); #endif /* Other OSs */ +} -- Alexander Pohoyda From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 08:20:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC62337B401 for ; Sun, 20 Apr 2003 08:20:23 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82B0D43FDD for ; Sun, 20 Apr 2003 08:20:22 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3KFKJVh052283; Sun, 20 Apr 2003 17:20:19 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 20 Apr 2003 17:20:19 +0200 (CEST) From: Martin Blapp To: Alexander Pohoyda In-Reply-To: <87n0il1b0b.fsf@oak.pohoyda.family> Message-ID: <20030420171922.Q95995@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030420014419.T95995@cvs.imp.ch> <87n0il1b0b.fsf@oak.pohoyda.family> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 15:20:24 -0000 Hi, > Might be a good idea to move a closing bracket outside of the ifdef: Thanks, fixed ! I also fixed the initialisation of the polling_interval variable if no value was given with -i. Martin From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 09:38:39 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5F6737B401 for ; Sun, 20 Apr 2003 09:38:39 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 395DF43FAF for ; Sun, 20 Apr 2003 09:38:36 -0700 (PDT) (envelope-from alexander.pohoyda@gmx.net) Received: (qmail 27222 invoked by uid 65534); 20 Apr 2003 16:38:34 -0000 Received: from p508BE949.dip.t-dialin.net (EHLO oak.pohoyda.family) (80.139.233.73) by mail.gmx.net (mp010-rz3) with SMTP; 20 Apr 2003 18:38:34 +0200 Received: from oak.pohoyda.family (oak.pohoyda.family [127.0.0.1]) by oak.pohoyda.family (8.12.8/8.12.6) with ESMTP id h3KGcVfH003965; Sun, 20 Apr 2003 18:38:31 +0200 (CEST) (envelope-from apog@oak.pohoyda.family) Received: (from apog@localhost) by oak.pohoyda.family (8.12.8/8.12.6/Submit) id h3KGcUlo003962; Sun, 20 Apr 2003 18:38:30 +0200 (CEST) (envelope-from apog) Date: Sun, 20 Apr 2003 18:38:30 +0200 (CEST) Message-Id: <200304201638.h3KGcUlo003962@oak.pohoyda.family> From: Alexander Pohoyda To: Martin Blapp In-reply-to: <20030420171922.Q95995@cvs.imp.ch> (message from Martin Blapp on Sun, 20 Apr 2003 17:20:19 +0200 (CEST)) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit References: <20030418132152.X6156@cvs.imp.ch> <20030420014419.T95995@cvs.imp.ch><20030420171922.Q95995@cvs.imp.ch> cc: hackers@freebsd.org Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 16:38:40 -0000 Hi Martin, > Thanks, fixed ! I also fixed the initialisation of the polling_interval > variable if no value was given with -i. I'm trying to test your patch. It applied OK to my FreeBSD oak.pohoyda.family 4.7-RELEASE-p7 FreeBSD 4.7-RELEASE-p7 #1: Sun Mar 9 15:24:53 CET 2003 apog@oak.pohoyda.family:/usr/obj/usr/src/sys/OAK i386 but then: ... ===> client cc -O -pipe -DCLIENT_PATH='"PATH=/sbin:/bin:/usr/sbin:/usr/bin"' -Dwarn=dhcp_warn -I/usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/includes -DENABLE_POLLING_MODE -c /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/clparse.c cc -O -pipe -DCLIENT_PATH='"PATH=/sbin:/bin:/usr/sbin:/usr/bin"' -Dwarn=dhcp_warn -I/usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/includes -DENABLE_POLLING_MODE -c /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/dhclient.c /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/dhclient.c: In function `main': /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/dhclient.c:209: `polling_interval' undeclared (first use in this function) /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/dhclient.c:209: (Each undeclared identifier is reported only once /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/dhclient.c:209: for each function it appears in.) /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/dhclient.c: In function `state_link': /usr/src/sbin/dhclient/client/../../../contrib/isc-dhcp/client/dhclient.c:3204: `doinitcheck' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sbin/dhclient/client. *** Error code 1 Stop in /usr/src/sbin/dhclient. I'll try to fix this and will report the result. -- Alexander Pohoyda From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 09:50:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5976637B401 for ; Sun, 20 Apr 2003 09:50:11 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2CBB43F3F for ; Sun, 20 Apr 2003 09:50:09 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3KGo5Vh060193; Sun, 20 Apr 2003 18:50:05 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 20 Apr 2003 18:50:05 +0200 (CEST) From: Martin Blapp To: Alexander Pohoyda In-Reply-To: <200304201638.h3KGcUlo003962@oak.pohoyda.family> Message-ID: <20030420184849.E95995@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030420014419.T95995@cvs.imp.ch><20030420171922.Q95995@cvs.imp.ch> <200304201638.h3KGcUlo003962@oak.pohoyda.family> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 16:50:11 -0000 Hi, > > I'm trying to test your patch. It applied OK to my > FreeBSD oak.pohoyda.family 4.7-RELEASE-p7 FreeBSD 4.7-RELEASE-p7 #1: Sun Mar 9 15:24:53 CET 2003 apog@oak.pohoyda.family:/usr/obj/usr/src/sys/OAK i386 > cd /usr/src/sbin/dhclient make clean make depend make make install should definitly work. Your line count in the error message doesn't fit to the patched version. Have you really the latest download ? Martin From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 09:55:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA4C37B405; Sun, 20 Apr 2003 09:55:41 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71C7043F85; Sun, 20 Apr 2003 09:55:40 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id BFC2C7; Sun, 20 Apr 2003 11:55:39 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 11A0878C66; Sun, 20 Apr 2003 11:55:39 -0500 (CDT) Date: Sun, 20 Apr 2003 11:55:38 -0500 From: "Jacques A. Vidrine" To: "Crist J. Clark" , freebsd-hackers@FreeBSD.org Message-ID: <20030420165538.GA31101@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Crist J. Clark" , freebsd-hackers@FreeBSD.org References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030416123621.GC72501@madman.celabo.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 16:55:45 -0000 On Wed, Apr 16, 2003 at 07:36:21AM -0500, Jacques A. Vidrine wrote: > On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote: > > 'uname -a'? > > The endpoints were both 4.7. > > > I can't reproduce this on a 4.8 to 4.7 tunnel. On > > 192.168.64.70, > > > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > > > And on 192.168.64.20, the gateway to 10.0.0.0/24, > > > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P in > > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > spdadd 10.0.0.0/24 192.168.64.70/32 any -P out > > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > > > Works fine. > > Hmm, yes, that appears to be exactly what I'm trying to do. Well, > that's heartening ... it means that there is likely some anomoly in my > environment that is hosing me. Now if only I can figure what it is :-) Oddly enough ... ESP works, AH does not. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 10:20:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8152337B409; Sun, 20 Apr 2003 10:20:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCA8B43F75; Sun, 20 Apr 2003 10:20:55 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-121.we.client2.attbi.com [24.130.112.121]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3KHKt123077; Sun, 20 Apr 2003 10:20:55 -0700 (PDT) Message-ID: <3EA2D6F5.4060209@isi.edu> Date: Sun, 20 Apr 2003 10:20:53 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> In-Reply-To: <20030420165538.GA31101@madman.celabo.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000906080205040907010104" cc: freebsd-hackers@FreeBSD.org cc: "Crist J. Clark" Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 17:20:59 -0000 This is a cryptographically signed message in MIME format. --------------ms000906080205040907010104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 4/20/2003 9:55 AM, Jacques A. Vidrine wrote: > On Wed, Apr 16, 2003 at 07:36:21AM -0500, Jacques A. Vidrine wrote: > >>On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote: >> >>>'uname -a'? >> >>The endpoints were both 4.7. >> >> >>>I can't reproduce this on a 4.8 to 4.7 tunnel. On >>>192.168.64.70, >>> >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P out >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P in >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; >>> >>>And on 192.168.64.20, the gateway to 10.0.0.0/24, >>> >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P in >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P out >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; >>> >>>Works fine. >> >>Hmm, yes, that appears to be exactly what I'm trying to do. Well, >>that's heartening ... it means that there is likely some anomoly in my >>environment that is hosing me. Now if only I can figure what it is :-) > > > Oddly enough ... ESP works, AH does not. Are you going through a NAT box? (Sorry, haven't been following this thread closely.) AH includes more of the IP header when computing the crypto checksum (compared to ESP), if those fields get diddled by a NAT box, the receiver will drop the packets because of bad crypto. One of the netstat counters on the receiver will show this. If you need to authenticate, maybe try using ESP authentication? Lars -- Lars Eggert USC Information Sciences Institute --------------ms000906080205040907010104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQyMDE3MjA1M1owIwYJKoZIhvcNAQkEMRYEFJD0PFrcil1lpIlT3tfs R5kvi6+MMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAOvAnoNOnD0bQivWABcMY3auJlGb4u6x4p+bQ XQaTy02yLSo4WHfG2NjMoEPk2JqPxRPclBXZt9dJqMSosxqzXdENLiuzkvLFZMXG99LZsD7r CccdXFZFVHmiq55zADvG3Bd9NxChSpuq2Wq1dl7MxH7sWLty8d+rtZDPWl+866CS37Wv1VL6 VxXhbB0UeWPda9pqMu9Ipma5k03tHjTS+L49M2sKpV6pU90YVctKMuTurtiUDzqOy5OuC4uv AMOLzwHCuP/OneKC3SEzr0WGqAObiDpxbinOVn1UbN1wjIBMRrKpcj5/9H5VhqAnbjipn/yB Op4jwmCtmfBD+XvICwAAAAAAAA== --------------ms000906080205040907010104-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 13:28:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6CE337B401; Sun, 20 Apr 2003 13:28:01 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4239543FAF; Sun, 20 Apr 2003 13:28:01 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0099.cvx21-bradley.dialup.earthlink.net ([209.179.192.99] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197LPr-0005tN-00; Sun, 20 Apr 2003 13:28:00 -0700 Message-ID: <3EA3027B.F15A7374@mindspring.com> Date: Sun, 20 Apr 2003 13:26:35 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis References: <200304201018.h3KAI5XB021318@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a485494447d9f98cb68f43988a39b73755548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: demon@FreeBSD.org cc: hackers@FreeBSD.org Subject: Re: Repeated similar panics on -STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 20:28:02 -0000 Don Lewis wrote: > On 20 Apr, Dmitry Sivachenko wrote: > > On Sun, Apr 20, 2003 at 01:16:16AM -0700, Don Lewis wrote: > > Well, here is probably a misunderstanding.. > > We did NOT apply Terry's patch. Let me quote a bit from my e-mail to Terry: > > > > TL> Did my patch fix your problem? > > TL> > > TL> Or did you tune your kernel, as I suggested, to fix your problem? > > TL> > > TL> Or is it still a problem? > > > > DS>We changed maxusers from 512 to 0 and decreased the number of > > DS>NMBCLUSTERS. Now everything is working fine, but since these panics occured > > DS>about once a week I can't say for sure they are completely gone. > > DS>Let's wait at least one more week... > > > > Thus I wanted to say that we only tuned maxusers and NMBCLUSTERS. We > > run virgin -STABLE kernel without any patches. Probably my english leaves much > > to be desired ;-(( > > Your English seems just fine to me. > > I just got the impression from Terry that the patch is what fixed the > problem for you. FWIW, I got the same impression from Dmitry. In any case, the retry in case the thing is NULL is valid, if the thing is ever NULL. The question of whether or not it can ever validly be NULL is really a sidebar. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 13:59:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46DA137B401; Sun, 20 Apr 2003 13:59:09 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A0FE43FDD; Sun, 20 Apr 2003 13:59:08 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003042020590600100a4j6ge>; Sun, 20 Apr 2003 20:59:06 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3KKx5ki000369; Sun, 20 Apr 2003 13:59:05 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3KKx5om000368; Sun, 20 Apr 2003 13:59:05 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sun, 20 Apr 2003 13:59:01 -0700 From: "Crist J. Clark" To: "Jacques A. Vidrine" , freebsd-hackers@FreeBSD.org Message-ID: <20030420205901.GA99917@blossom.cjclark.org> References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420165538.GA31101@madman.celabo.org> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 20:59:09 -0000 On Sun, Apr 20, 2003 at 11:55:38AM -0500, Jacques A. Vidrine wrote: > On Wed, Apr 16, 2003 at 07:36:21AM -0500, Jacques A. Vidrine wrote: > > On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote: > > > 'uname -a'? > > > > The endpoints were both 4.7. > > > > > I can't reproduce this on a 4.8 to 4.7 tunnel. On > > > 192.168.64.70, > > > > > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > > > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > > spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > > > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > > > > > And on 192.168.64.20, the gateway to 10.0.0.0/24, > > > > > > spdadd 192.168.64.70/32 10.0.0.0/24 any -P in > > > ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > > spdadd 10.0.0.0/24 192.168.64.70/32 any -P out > > > ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > > > > > Works fine. > > > > Hmm, yes, that appears to be exactly what I'm trying to do. Well, > > that's heartening ... it means that there is likely some anomoly in my > > environment that is hosing me. Now if only I can figure what it is :-) > > Oddly enough ... ESP works, AH does not. Yep, I can reproduce that. This setup, bubbles# cat bubbles.spd # Security Policy Database spdadd 192.168.64.70/32 10.0.0.0/24 any -P out ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; spdadd 10.0.0.0/24 192.168.64.70/32 any -P in ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; # Security Associations Database add 192.168.64.70 192.168.64.20 esp 0x4321 -m tunnel -r 128 -E rijndael-cbc "encryption keys1" -A hmac-md5 "testkey1testkey2"; add 192.168.64.20 192.168.64.70 esp 0x1234 -m tunnel -r 128 -E rijndael-cbc "encryption keys2" -A hmac-md5 "testkey2testkey1"; Works great with the apropriate swapping in the SPD on the other end of the tunnel. However, do the following to both, bubbles# ed bubbles.spd g/esp/s/esp/ah/ g/-E/s/^/#/ wq bubbles# setkey -F; setkey -FP; setkey -f bubbles.spd And things do not work. The sender seems to work fine, but the receiver increments the, "inbound packets violated process security policy" Counter. But the really puzzling part is that it increments the, "inbound packets processed successfully" (which I think I understand) "inbound packets considered authentic" (which I do not) Counters too. Your conjecture that it may be somehow processing inbound packets twice may be on the right track. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 14:01:21 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C373C37B401 for ; Sun, 20 Apr 2003 14:01:21 -0700 (PDT) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id E06C143FE1 for ; Sun, 20 Apr 2003 14:01:20 -0700 (PDT) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 21558 invoked by uid 1500); 20 Apr 2003 21:01:18 -0000 Date: Sun, 20 Apr 2003 17:01:18 -0400 From: "Kevin A. Pieckiel" To: freebsd-hackers@freebsd.org Message-ID: <20030420210118.GA21255@pacer.dmz.smartrafficenter.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 21:01:22 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline First, do open sockets (inet or unix) or pipes (via pipe(2)) count against kern.maxfiles, kern.maxfilesperproc, and other related limits? Second, are there sysctl variables that indicate the size or usage of the file table? Or is this simply indicated by maxfiles (and perhaps others)? Or is there a program that will report this info? Third, where is the limit for the number of file descriptors that can be open set? Or is this the same limit as maxfiles, etc? Fourth, is there a difference between an open file and an open descriptor? These questions were spawned from the errors possibly returned by pipe(2). I'm not clear on what the entities and limits are as they involve such things as the file table, open files, open descriptors, etc. Finally, are answers to these questions OS specific, or are they part of a standard indicating how such things behave? Thanks, Kevin "Beware when the great God lets loose a thinker on this planet." -- Ralph Waldo Emerson --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+owqac3iJbvFgTpIRAgJjAJwMBECbgJ/hCbRMNEOm64lmSCQs8QCfeaIW pBhDBqf3o5b9Aytj1giJJ00= =CFnT -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 14:11:07 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3FE837B401; Sun, 20 Apr 2003 14:11:07 -0700 (PDT) Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id C75C843F3F; Sun, 20 Apr 2003 14:11:06 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) ESMTP id h3KKCgCr000515; Sun, 20 Apr 2003 13:12:48 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Sender: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net Message-ID: <3EA2FF3A.4D86D5CB@lbl.gov> Date: Sun, 20 Apr 2003 13:12:42 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: bj@dc.luth.se, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org References: <200304191305.h3JD5S2F026929@dc.luth.se> <3EA20D31.2606389B@lbl.gov> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 21:11:08 -0000 Now the patch is ready. It has been tested on both 4.7 and 4.8. For 4.7, one has to manually add an empty line before the comment prior to the tcp_output() routine. Some more hints for tracing: (net.inet.tcp.liondmask is a bitmap) bit 0-1 (value 1, 2, or 3) is for enabling tcp_output() mbuf chain modification bit 2 (value 4) is for enabling sbappend() mbuf chain modification bit 3 (value 8) is for tcp_input (DO NOT TRY IT, it is not ready). bit 9 (value 512) is for enabling check routine (dump errors to /var/log/messag). If you do have problem, set net.inet.tcp.liondmask to 512 and look what message says. If you would like to know which part causing problem or not working properly, set net.inet.tcp.liondmask to 1, 2, 3 or 4 to test individual module. -Jin "Jin Guojun [NCS]" wrote: > Not yet. I said I will send out email when it is ready. > The problem is we have a significantly modified system based on 4.8-RC2. I tried to > extract the only > sockbut/mbuf code, but it apparently, the patch is in completed for pure 4.8 system. > Somehow, it have > some depenency of our new TCP stack. > > So, I am building two new systems, one pure 4.7 and one pure 4.8. I will extract correct > patch for these > system, test them, then send out another email. > > Thanks for the patient. > > -Jin > > Borje Josefsson wrote: > > > Hmm. I'm not sure if I misunderstood if this was ready for another test > > run or not. Anyhow - I took the new patch .tgz (which, btw, still had > > tcp_input.p in it). I applied the patches (except tcp_input) and tested. > > > > Now I get: > > > > Panic: bad cur_off > > 00000 m_p 0xc0a7f400 0xc0a7f400 my_off 0 1448 cc 3407144 > > > > As usual, I'm willing to test more when there are an update available. > > > > --Börje > > > > On Fri, 18 Apr 2003 13:04:24 PDT "Jin Guojun [DSD]" wrote: > > > > > Opps, there was a bad file -- tcp_input.p -- which is not working yet. > > > Also, a patch file -- tcp_usrreq.p -- was missing. > > > > > > I will take the tcp_input.p out and put tcp_usrreq.p in. > > > When it is finished, I will send another mail out. > > > > > > -Jin > > > > > > Borje Josefsson wrote: > > > > > > > On Thu, 17 Apr 2003 22:12:02 PDT "Jin Guojun [NCS]" wrote: > > > > > > > > > I have modified the sockbuf and mbuf operation to double the throughput over > > > > > high bandwidth delay product path. > > > > > > > > > > The patch is available at: > > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#FreeBSD_Patches > > > > > > > > > > The current modification is for tcp transmission only. > > > > > > > > > > I have adapted some code of uipc_socket2.c from Sam Leffler > > > > > http://www.freebsd.org/~sam/thorpe-stable.patch > > > > > > > > > > for tcp receiver, but it has not been tested yet, so the tcp_input.p is empty. > > > > > > > > > > I ignored all record chain (m_nextpkt) related code. The details is explained at > > > > > > > > > > http://www-didc.lbl.gov/~jin/network/lion/content.html#BSDMbuf > > > > > > > > > > Once the tcp_input code is tested, I will submit the patch to bugs@freebsd.org. > > > > > I may submit the patch regardless if tcp_input code works or not, because the > > > > > tcp > > > > > sender (server) is more important in high-speed network than the receiver > > > > > (client). > > > > > > > > > > It is appreciated if any one can verify the patch and provide feedback. > > > > > > > > OK. I have now tried this patch on a newly-installed 4.8R. The patch > > > > applied fine. When the sysctl net.inet.tcp.liondmask is unset, everything > > > > seems OK, but when setting it to 7 (as specified with the patch > > > > instructions) i get: > > > > > > > > Fatal trap 12: page fault while in kernel mode. > > > > (I could write down all the stuff on addresses etc if it makes sense) > > > > > > > > when I run ttcp to test the performance. > > > > > > > > This is repeatable. > > > > > > > > I'm willing to test more, if someone provides me with some hints on what > > > > to do. > > > > > > > > --Börje From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 14:11:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B08E37B401; Sun, 20 Apr 2003 14:11:37 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A53D43F75; Sun, 20 Apr 2003 14:11:36 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <200304202111350030054db1e>; Sun, 20 Apr 2003 21:11:35 +0000 Date: Sun, 20 Apr 2003 14:11:34 -0700 (PDT) From: Doug Barton To: Alex Semenyaka In-Reply-To: <20030419062121.GA70121@snark.ratmir.ru> Message-ID: <20030420140851.H631@znfgre.tberna.bet> References: <20030419062121.GA70121@snark.ratmir.ru> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-gnats-submit@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: bin/51148 Slow vipw and fast pwd_mkdb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 21:11:38 -0000 On Sat, 19 Apr 2003, Alex Semenyaka wrote: > Hello, > > could somebody to comment PR bin/51148? It is suggestion how to pass > a value of cache size to pwd_mkdb when we are doing vipw or such. > It can give a greate speed-up when master.passwd is really big (and > sometimes it is). Appropriate cache size can make process 10 to 100 > or more times faster. I gave the results of measurements in that > problem report. Having been in a "mondo huge master.passwd file" situation myself, my comment is that people in this situation should probably not be relying on tools like vipw to manage their stuff. However, my feelings aren't strong enough to prompt me to close your PR, so good luck. :) Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 14:25:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83F2737B401 for ; Sun, 20 Apr 2003 14:25:14 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A7F343FDF for ; Sun, 20 Apr 2003 14:25:12 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030420212511053002gimge>; Sun, 20 Apr 2003 21:25:11 +0000 Date: Sun, 20 Apr 2003 14:25:11 -0700 (PDT) From: Doug Barton To: Martin Blapp In-Reply-To: <20030418132152.X6156@cvs.imp.ch> Message-ID: <20030420142318.J631@znfgre.tberna.bet> References: <20030418132152.X6156@cvs.imp.ch> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org cc: imp@imp.com Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 21:25:14 -0000 On Fri, 18 Apr 2003, Martin Blapp wrote: > > Hi all, > > Already promised a few times, now I have done it :) > > Many of you may have a laptop and already had it a few times > happen that the new IP didn't got set automatically. So you > had to kill dhclient and restart it again. I think this is an interesting idea, but I wonder if you've discussed this with the isc-dhcp folks? In my experience with dhcp, there are a lot of things that seem like good ideas, but don't work well in practice for a variety of non-obvious reasons. In this area, it's good to consult the experts. My other question is, have you tested this with a wireless device? Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 14:41:45 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC4A937B401; Sun, 20 Apr 2003 14:41:45 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C7943FDF; Sun, 20 Apr 2003 14:41:44 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3KLfaVh085891; Sun, 20 Apr 2003 23:41:36 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 20 Apr 2003 23:41:36 +0200 (CEST) From: Martin Blapp To: Doug Barton In-Reply-To: <20030420142318.J631@znfgre.tberna.bet> Message-ID: <20030420233651.S95995@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030420142318.J631@znfgre.tberna.bet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org cc: imp@imp.com Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 21:41:46 -0000 Hi, > I think this is an interesting idea, but I wonder if you've discussed this > with the isc-dhcp folks? In my experience with dhcp, there are a lot of I've sent it to the isc dhcpclient mailing list. > My other question is, have you tested this with a wireless device? No. If you have one, can you do some tests for me ? But for some obvious reasons, it really makes no sense to send requests on a device which has no active link. I was also not able to test it on my laptop with cardbus devices, since my laptop still freezes if I remove my card: ep0: <3Com Megahertz 574B> at port 0x100-0x11f irq 11 function 0 config 1 on pccard1 ep0: Ethernet address 00:50:da:e4 Martin From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 15:01:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81DAC37B401; Sun, 20 Apr 2003 15:01:24 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66B2C43F93; Sun, 20 Apr 2003 15:01:23 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3KM1MA7019743; Sun, 20 Apr 2003 16:01:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 20 Apr 2003 16:00:39 -0600 (MDT) Message-Id: <20030420.160039.89787228.imp@bsdimp.com> To: mb@imp.ch From: "M. Warner Losh" In-Reply-To: <20030420233651.S95995@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030420142318.J631@znfgre.tberna.bet> <20030420233651.S95995@cvs.imp.ch> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: DougB@freebsd.org cc: imp@imp.com Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 22:01:24 -0000 In message: <20030420233651.S95995@cvs.imp.ch> Martin Blapp writes: : ep0: <3Com Megahertz 574B> at port 0x100-0x11f irq 11 function 0 config 1 on pccard1 : ep0: Ethernet address 00:50:da:e4 Hmmmm, freezes you say? Can you break into the debugger? Can you get me more inforamtion? I think that this might be epintr looping forever :-( Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 15:59:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B891837B401; Sun, 20 Apr 2003 15:59:11 -0700 (PDT) Received: from speicher.org (sirius.speicher.org [209.74.10.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id D16E243FD7; Sun, 20 Apr 2003 15:59:09 -0700 (PDT) (envelope-from geoff@speicher.org) Received: from localhost (geoff@localhost) by speicher.org (8.11.6/8.11.6) with ESMTP id h3KNDUM57584; Sun, 20 Apr 2003 19:13:34 -0400 (EDT) (envelope-from geoff@speicher.org) Date: Sun, 20 Apr 2003 19:13:30 -0400 (EDT) From: "Geoffrey C. Speicher" To: Doug Barton In-Reply-To: <20030420140851.H631@znfgre.tberna.bet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-gnats-submit@freebsd.org cc: Alex Semenyaka cc: freebsd-stable@freebsd.org Subject: Re: bin/51148 Slow vipw and fast pwd_mkdb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 22:59:12 -0000 On Sun, 20 Apr 2003, Doug Barton wrote: > On Sat, 19 Apr 2003, Alex Semenyaka wrote: > > > Hello, > > > > could somebody to comment PR bin/51148? It is suggestion how to pass > > a value of cache size to pwd_mkdb when we are doing vipw or such. > > It can give a greate speed-up when master.passwd is really big (and > > sometimes it is). Appropriate cache size can make process 10 to 100 > > or more times faster. I gave the results of measurements in that > > problem report. > > Having been in a "mondo huge master.passwd file" situation myself, my > comment is that people in this situation should probably not be relying on > tools like vipw to manage their stuff. However, my feelings aren't strong > enough to prompt me to close your PR, so good luck. :) Are your feelings strong enough to commit bin/38676 so that people can use pw(8) safely and concurrently on mondo huge master.passwd files? :) bin/23501 was supposed to have fixed the problem, but it doesn't appear to have been committed before it was closed. bin/38676 is a revised/improved version of the original patch in bin/23501. Geoff From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 16:20:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F4CC37B401 for ; Sun, 20 Apr 2003 16:20:32 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB8543F75 for ; Sun, 20 Apr 2003 16:20:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0075.cvx21-bradley.dialup.earthlink.net ([209.179.192.75] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197O6W-0000Ow-00; Sun, 20 Apr 2003 16:20:13 -0700 Message-ID: <3EA32ADA.CC05B003@mindspring.com> Date: Sun, 20 Apr 2003 16:18:50 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin A. Pieckiel" References: <20030420210118.GA21255@pacer.dmz.smartrafficenter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42265d4e63792ddd1b6174dbe625b5f1a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 23:20:32 -0000 "Kevin A. Pieckiel" wrote: > First, do open sockets (inet or unix) or pipes (via pipe(2)) count > against kern.maxfiles, kern.maxfilesperproc, and other related limits? Yes. And the limits are not runtime settable. > Second, are there sysctl variables that indicate the size or usage > of the file table? Or is this simply indicated by maxfiles (and > perhaps others)? Or is there a program that will report this info? The "lsof" program will report open files. The "maxfiles" variable is a limit. The limit is runtime for files, boot time for sockets. The value of "kern.openfiles" is valid, but not very useful. > Third, where is the limit for the number of file descriptors that > can be open set? Or is this the same limit as maxfiles, etc? It's "maxfiles". > Fourth, is there a difference between an open file and an open > descriptor? Not specifically. Practically, no. > These questions were spawned from the errors possibly returned by > pipe(2). I'm not clear on what the entities and limits are as > they involve such things as the file table, open files, open > descriptors, etc. > > Finally, are answers to these questions OS specific, or are they > part of a standard indicating how such things behave? They are pretty much OS specific, for the answers. The questions aren't. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 16:26:17 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F14D437B401; Sun, 20 Apr 2003 16:26:16 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DD8843FD7; Sun, 20 Apr 2003 16:26:16 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 9F50953; Sun, 20 Apr 2003 18:26:15 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id EA8C178C66; Sun, 20 Apr 2003 18:26:14 -0500 (CDT) Date: Sun, 20 Apr 2003 18:26:14 -0500 From: "Jacques A. Vidrine" To: Lars Eggert Message-ID: <20030420232614.GA41554@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Lars Eggert , "Crist J. Clark" , freebsd-hackers@FreeBSD.org References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> <3EA2D6F5.4060209@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA2D6F5.4060209@isi.edu> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-hackers@FreeBSD.org cc: "Crist J. Clark" Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 23:26:17 -0000 On Sun, Apr 20, 2003 at 10:20:53AM -0700, Lars Eggert wrote: > On 4/20/2003 9:55 AM, Jacques A. Vidrine wrote: > >On Wed, Apr 16, 2003 at 07:36:21AM -0500, Jacques A. Vidrine wrote: > > > >>On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote: > >> > >>>'uname -a'? > >> > >>The endpoints were both 4.7. > >> > >> > >>>I can't reproduce this on a 4.8 to 4.7 tunnel. On > >>>192.168.64.70, > >>> > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > >>> > >>>And on 192.168.64.20, the gateway to 10.0.0.0/24, > >>> > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P in > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P out > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > >>> > >>>Works fine. > >> > >>Hmm, yes, that appears to be exactly what I'm trying to do. Well, > >>that's heartening ... it means that there is likely some anomoly in my > >>environment that is hosing me. Now if only I can figure what it is :-) > > > > > >Oddly enough ... ESP works, AH does not. > > Are you going through a NAT box? (Sorry, haven't been following this > thread closely.) AH includes more of the IP header when computing the > crypto checksum (compared to ESP), if those fields get diddled by a NAT > box, the receiver will drop the packets because of bad crypto. One of > the netstat counters on the receiver will show this. No NAT. > If you need to authenticate, maybe try using ESP authentication? Yes, I believe that's what I tested. e.g. 223.223.223.223 117.117.117.117 esp mode=tunnel spi=40396514(0x26866e25) reqid=0(0x00000000) E: 3des-cbc 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14 1e11dd81 A: hmac-sha1 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Mar 2 07:52:31 2003 current: Mar 2 07:59:28 2003 diff: 20(s) hard: 30(s) soft: 24(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=2 pid=90010 refcnt=1 I actually don't need AH ... I was using AH because it is easier to see what is going on. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 16:27:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 053DA37B401 for ; Sun, 20 Apr 2003 16:27:48 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BD9A43FBD for ; Sun, 20 Apr 2003 16:27:45 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id B71CA53; Sun, 20 Apr 2003 18:27:44 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 46F8078C66; Sun, 20 Apr 2003 18:27:44 -0500 (CDT) Date: Sun, 20 Apr 2003 18:27:44 -0500 From: "Jacques A. Vidrine" To: cjclark@alum.mit.edu Message-ID: <20030420232744.GB41554@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , cjclark@alum.mit.edu, freebsd-hackers@FreeBSD.org References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> <20030420205901.GA99917@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420205901.GA99917@blossom.cjclark.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-hackers@FreeBSD.org Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 23:27:48 -0000 On Sun, Apr 20, 2003 at 01:59:01PM -0700, Crist J. Clark wrote: > Yep, I can reproduce that. This setup, [...] > Works great with the apropriate swapping in the SPD on the other end > of the tunnel. However, do the following to both, > > bubbles# ed bubbles.spd > g/esp/s/esp/ah/ > g/-E/s/^/#/ > wq > bubbles# setkey -F; setkey -FP; setkey -f bubbles.spd > > And things do not work. The sender seems to work fine, but the > receiver increments the, > > "inbound packets violated process security policy" > > Counter. But the really puzzling part is that it increments the, > > "inbound packets processed successfully" (which I think I understand) > "inbound packets considered authentic" (which I do not) > > Counters too. > > Your conjecture that it may be somehow processing inbound packets > twice may be on the right track. Thanks for double-checking, Crist. Unfortunately I don't have the cycles right now to track it down. I hope anyone who encounters the same issue will come across this thread in the archives. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 16:31:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98A2B37B401 for ; Sun, 20 Apr 2003 16:31:41 -0700 (PDT) Received: from saturn.bsdhome.com (rrcs-midsouth-24-199-212-224.biz.rr.com [24.199.212.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A4543FDF for ; Sun, 20 Apr 2003 16:31:40 -0700 (PDT) (envelope-from bsd@bsdhome.com) Received: from neutrino.bsdhome.com (jupiter [192.168.220.13]) by saturn.bsdhome.com (8.12.9/8.12.9) with ESMTP id h3KNVWam000406 for ; Sun, 20 Apr 2003 19:31:32 -0400 (EDT) (envelope-from bsd@bsdhome.com) Received: from neutrino.bsdhome.com (localhost [127.0.0.1]) by neutrino.bsdhome.com (8.12.9/8.12.9) with ESMTP id h3KNVYPv000824; Sun, 20 Apr 2003 19:31:34 -0400 (EDT) (envelope-from bsd@neutrino.bsdhome.com) Received: (from bsd@localhost) by neutrino.bsdhome.com (8.12.9/8.12.9/Submit) id h3KNVXNv000823; Sun, 20 Apr 2003 19:31:33 -0400 (EDT) (envelope-from bsd) Date: Sun, 20 Apr 2003 19:31:33 -0400 From: Brian Dean To: freebsd-hackers@freebsd.org Message-ID: <20030420233133.GA593@neutrino.bsdhome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: using x11 forwarding with ssh from a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 23:31:41 -0000 Hi, Is anyone having problems connecting to their X server from inside a jail using ssh's X11 forwarding? >From my non-jail environment, I ssh into my jail environment with X11 forwarding enabled. When I try to invoke an X application, I get: % xclock X11 connection rejected because of wrong authentication. X connection to localhost:11.0 broken (explicit kill or server shutdown). It works fine if I uset 'xhost +' in my non-jail environment and the point my display appropriately from inside the jail (bypassing ssh x11 forwarding). Any ideas why X11 forwarding doesn't seem to do the right thing? -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com http://www.bsdhome.com/ http://www.bdmicro.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 18:00:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1658037B401; Sun, 20 Apr 2003 18:00:34 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C79C43F85; Sun, 20 Apr 2003 18:00:32 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <200304210100310020027cche>; Mon, 21 Apr 2003 01:00:31 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3L10Qki001264; Sun, 20 Apr 2003 18:00:30 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3L10PwB001263; Sun, 20 Apr 2003 18:00:25 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sun, 20 Apr 2003 18:00:25 -0700 From: "Crist J. Clark" To: "Jacques A. Vidrine" , Lars Eggert , freebsd-hackers@FreeBSD.org Message-ID: <20030421010025.GB99917@blossom.cjclark.org> References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> <3EA2D6F5.4060209@isi.edu> <20030420232614.GA41554@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420232614.GA41554@madman.celabo.org> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 01:00:34 -0000 On Sun, Apr 20, 2003 at 06:26:14PM -0500, Jacques A. Vidrine wrote: > On Sun, Apr 20, 2003 at 10:20:53AM -0700, Lars Eggert wrote: > > On 4/20/2003 9:55 AM, Jacques A. Vidrine wrote: > > >On Wed, Apr 16, 2003 at 07:36:21AM -0500, Jacques A. Vidrine wrote: > > > > > >>On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote: > > >> > > >>>'uname -a'? > > >> > > >>The endpoints were both 4.7. > > >> > > >> > > >>>I can't reproduce this on a 4.8 to 4.7 tunnel. On > > >>>192.168.64.70, > > >>> > > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P out > > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P in > > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > >>> > > >>>And on 192.168.64.20, the gateway to 10.0.0.0/24, > > >>> > > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P in > > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require; > > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P out > > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require; > > >>> > > >>>Works fine. > > >> > > >>Hmm, yes, that appears to be exactly what I'm trying to do. Well, > > >>that's heartening ... it means that there is likely some anomoly in my > > >>environment that is hosing me. Now if only I can figure what it is :-) > > > > > > > > >Oddly enough ... ESP works, AH does not. > > > > Are you going through a NAT box? (Sorry, haven't been following this > > thread closely.) AH includes more of the IP header when computing the > > crypto checksum (compared to ESP), if those fields get diddled by a NAT > > box, the receiver will drop the packets because of bad crypto. One of > > the netstat counters on the receiver will show this. > > No NAT. > > > If you need to authenticate, maybe try using ESP authentication? > > Yes, I believe that's what I tested. e.g. > > 223.223.223.223 117.117.117.117 > esp mode=tunnel spi=40396514(0x26866e25) reqid=0(0x00000000) > E: 3des-cbc 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14 1e11dd81 > A: hmac-sha1 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14 > seq=0x00000000 replay=4 flags=0x00000000 state=mature > created: Mar 2 07:52:31 2003 current: Mar 2 07:59:28 2003 > diff: 20(s) hard: 30(s) soft: 24(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=2 pid=90010 refcnt=1 > > I actually don't need AH ... I was using AH because it is easier to see > what is going on. It's easy to see what's going on in ESP when you define the encryption algorithm as the NULL algorithm. Although I admit it took me a while to figure out that NULL encryption in the setkey(8) syntax is the "simple" algorithm. In fact, would anyone object to, Index: setkey.8 =================================================================== RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/setkey.8,v retrieving revision 1.24 diff -u -r1.24 setkey.8 --- setkey.8 1 Jan 2003 18:49:03 -0000 1.24 +++ setkey.8 21 Apr 2003 00:41:50 -0000 @@ -563,7 +563,7 @@ algorithm keylen (bits) comment des-cbc 64 esp-old: rfc1829, esp: rfc2405 3des-cbc 192 rfc2451 -simple 0 to 2048 rfc2410 +null-enc 0 to 2048 rfc2410 blowfish-cbc 40 to 448 rfc2451 cast128-cbc 40 to 128 rfc2451 des-deriv 64 ipsec-ciph-des-derived-01 (expired) Index: token.l =================================================================== RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/token.l,v retrieving revision 1.5 diff -u -r1.5 token.l --- token.l 11 Jun 2001 12:39:28 -0000 1.5 +++ token.l 21 Apr 2003 00:39:41 -0000 @@ -176,6 +176,7 @@ {hyphen}E { PREPROC; return(F_ENC); } des-cbc { PREPROC; yylval.num = SADB_EALG_DESCBC; return(ALG_ENC); } 3des-cbc { PREPROC; yylval.num = SADB_EALG_3DESCBC; return(ALG_ENC); } +null-enc { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); } simple { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); } blowfish-cbc { PREPROC; yylval.num = SADB_X_EALG_BLOWFISHCBC; return(ALG_ENC); } cast128-cbc { PREPROC; yylval.num = SADB_X_EALG_CAST128CBC; return(ALG_ENC); } The KAME stuff isn't on a vendor branch, not in a contrib/, and not listed in MAINTAINERS. I guess it's OK to make minor changes/bug fixes locally? I did file a PR with KAME for this too. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 22:53:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5415137B401 for ; Sun, 20 Apr 2003 22:53:34 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1998543FA3 for ; Sun, 20 Apr 2003 22:53:33 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h3L5rWwk088832 for ; Sun, 20 Apr 2003 22:53:32 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h3L5rWqW004735 for ; Sun, 20 Apr 2003 22:53:32 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h3L5rWpY004734 for freebsd-hackers@FreeBSD.org; Sun, 20 Apr 2003 22:53:32 -0700 (PDT) Date: Sun, 20 Apr 2003 22:53:32 -0700 From: Marcel Moolenaar To: freebsd-hackers@FreeBSD.org Message-ID: <20030421055332.GA4680@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: Is pmap_kextract() allowed to fault? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 05:53:34 -0000 Gang, On ia64 pmap_kextract() uses the tpa instruction which given a virtual address returns the physical address based on the translation registers and cache (ie TLB). This can fault when there's currently no mapping for the virtual address. Since all other architectures have a non-faulting implementation (AFAICT), I'm a bit worried that we might get into trouble on ia64. I couldn't find anything about pmap_kextract(), so maybe anybody can enlighten me: 1. Is pmap_kextract() allowed to fault? 2. Is pmap_kextract() used often enough that using the cpu's TLB is a possible performance speedup even if there are costly faults that can sometimes happen? Note: an implementation not based on the tpa instruction would look pretty much the same as the current sparc64 implementation. Just so you know... Thanks, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 01:28:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B19D37B401; Mon, 21 Apr 2003 01:28:03 -0700 (PDT) Received: from samson.dc.luth.se (samson.dc.luth.se [130.240.112.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C44EC43F93; Mon, 21 Apr 2003 01:28:01 -0700 (PDT) (envelope-from bj@dc.luth.se) Received: from dc.luth.se (root@bompe.dc.luth.se [130.240.60.42]) by samson.dc.luth.se (8.12.5/8.12.5) with ESMTP id h3L8S0LG003787; Mon, 21 Apr 2003 10:28:00 +0200 (MET DST) Received: from bompe.dc.luth.se (bj@localhost.dc.luth.se [127.0.0.1]) by dc.luth.se (8.12.6/8.11.3) with ESMTP id h3L8Rx2F032265; Mon, 21 Apr 2003 10:27:59 +0200 (CEST) (envelope-from bj@bompe.dc.luth.se) Message-Id: <200304210827.h3L8Rx2F032265@dc.luth.se> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Jin Guojun [NCS]" In-reply-to: Your message of Sun, 20 Apr 2003 13:12:42 PDT. <3EA2FF3A.4D86D5CB@lbl.gov> Dcc: From: Borje Josefsson X-Disposition-notification-to: Borje.Josefsson@dc.luth.se X-uri: http://www.dc.luth.se/~bj/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Apr 2003 10:27:59 +0200 Sender: bj@dc.luth.se cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bj@dc.luth.se List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 08:28:03 -0000 On Sun, 20 Apr 2003 13:12:42 PDT "Jin Guojun [NCS]" wrote: > Now the patch is ready. It has been tested on both 4.7 and 4.8. > For 4.7, one has to manually add an empty line before the comment prior= to the > tcp_output() routine. comment for beginning the tcp_output() in 4.7-RELEASE :-( > > = > Some more hints for tracing: (net.inet.tcp.liondmask is a bitmap) > bit 0-1 (value 1, 2, or 3) is for enabling tcp_output() mbuf chain modi= fication > bit 2 (value 4) is for enabling sbappend() mbuf chain modification > bit 3 (value 8) is for tcp_input (DO NOT TRY IT, it is not ready). > = > bit 9 (value 512) is for enabling check routine (dump errors to /var/lo= g/messag). > = > If you do have problem, set net.inet.tcp.liondmask to 512 and look what= message says. > If you would like to know which part causing problem or not working pro= perly, > set net.inet.tcp.liondmask to 1, 2, 3 or 4 to test individual module. Thanks!! This patch definitively works, and gives much higher PPS (32000 instead o= f = 19000). This is on a low-end system (PIII 900MHz with 33MHz bus), I'll = test one of my larger systems later today. One question though - is there any way of having the code being more = "aggressive"? As You see, in the netstat output below, it takes ~35 = seconds(!) before reaching full speed. On NetBSD I reach maxPPS almost = immediately. Even if we now (with Your patch) can utilize the hardware = much more, it only helps if You have connections that lasts for a very = long time, so that the "ramping" time is not significant. *Note* (the very last output below) that this seems to be highly dependan= t = on RTT. On a 2ms connection (~50 miles) I reach max RTT almost = immediately. (can't explain why I go to 51kpps and then fall back to = 35kpps, this is repeatable). Apart from vanilla 4.8R I have set: kern.ipc.maxsockbuf=3D8388608 net.inet.tcp.sendspace=3D3217968 net.inet.tcp.recvspace=3D3217968 kern.ipc.nmbclusters=3D8192 And this test is done on a connection with RTT in the order of 22 ms. --B=F6rje =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "netstat 1" **on NetBSD** (for comparat= ion) =3D=3D=3D=3D=3D bge0 in bge0 out total in total out packets errs packets errs colls packets errs packets 1 0 1 0 0 1 0 1 7118 0 11315 0 0 7118 0 11315 18604 0 28014 0 0 18604 0 28014 18610 0 28005 0 0 18611 0 28005 (NOTE that this example is using larger MTU, and not on the same hardware= = as below, but the behaviour of reaching maxPPS "immediately" is the same)= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "netstat 1" with liondmask=3D7 =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D input (Total) output packets errs bytes packets errs bytes colls 6 0 540 3 0 228 0 37 0 2712 56 0 72216 0 646 0 42636 823 0 1244686 0 1548 0 102168 1966 0 2975188 0 2432 0 160512 3039 0 4604252 0 3301 0 217866 4193 0 6345352 0 4174 0 275484 5254 0 7950192 0 5011 0 330726 6373 0 9650414 0 5836 0 385176 7448 0 11271908 0 6675 0 440550 8519 0 12896430 0 7528 0 496848 9596 0 14527008 0 8408 0 554928 10626 0 16089456 0 9212 0 607992 11652 0 17636764 0 9962 0 657492 12698 0 19223436 0 10699 0 706134 13694 0 20731380 0 11368 0 750288 14648 0 22175736 0 12144 0 801504 15697 0 23768464 0 12802 0 844932 16693 0 25267324 0 13412 0 885192 17552 0 26576934 0 14001 0 924066 18495 0 28001608 0 14444 0 953304 19415 0 29384230 0 15041 0 992706 20275 0 30701070 0 15681 0 1034946 21327 0 32283200 0 16224 0 1070784 22202 0 33610978 0 16621 0 1096986 22888 0 34651096 0 17050 0 1125300 23568 0 35682130 0 17721 0 1169586 24573 0 37200672 0 18256 0 1204896 25361 0 38401274 0 18782 0 1239612 26128 0 39550400 0 19359 0 1277694 26972 0 40834272 0 20150 0 1329900 28015 0 42413374 0 20900 0 1379400 28962 0 43854702 0 21523 0 1420518 30024 0 45447430 0 22256 0 1468896 30891 0 46767638 0 22882 0 1510212 31655 0 47924334 0 23087 0 1523742 31865 0 48243788 0 23225 0 1532850 32038 0 48502682 0 It seems that I reach the limit about here - 35-36 sec after start 23170 0 1529220 32121 0 48629858 0 23223 0 1532718 32036 0 48501168 0 23200 0 1531200 32121 0 48629858 0 23103 0 1524792 32122 0 48631372 0 23104 0 1524864 32080 0 48565096 0 23214 0 1532124 32079 0 48566270 0 23147 0 1527696 32036 0 48501168 0 10318 0 680988 13543 0 20495142 0 1 0 66 1 0 178 0 1 0 66 1 0 178 0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "netstat 1" with liondmask=3D7 =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D With plain 4.8 (liondmask=3D0) I get: root@stinky 8# netstat 1 input (Total) output packets errs bytes packets errs bytes colls 7 0 732 10 0 2394 0 437 0 28842 556 0 840448 0 1343 0 88638 1669 0 2531586 0 2201 0 145266 2757 0 4166706 0 3082 0 203406 3857 0 5841190 0 4021 0 265386 4959 0 7503562 0 4877 0 321882 6017 0 9111430 0 5621 0 370986 7064 0 10690532 0 6471 0 427086 8136 0 12319596 0 7216 0 476256 9177 0 13889614 0 8006 0 528396 10181 0 15415726 0 8725 0 575850 11215 0 16975146 0 9482 0 625812 12259 0 18561818 0 10205 0 673530 13258 0 20071276 0 10846 0 715836 14115 0 21365746 0 11563 0 763158 15223 0 23046286 0 12399 0 818334 16266 0 24628416 0 13024 0 859584 17119 0 25913802 0 13609 0 898194 17949 0 27173450 0 14316 0 944856 18798 0 28458836 0 14391 0 949806 18842 0 28522764 0 14463 0 954558 19010 0 28779804 0 Here I reach the limit after 20 seconds. 14500 0 957000 19095 0 28908494 0 14534 0 959244 19053 0 28844906 0 14599 0 963534 19052 0 28843392 0 14526 0 958716 19053 0 28844906 0 14484 0 955944 18967 0 28714702 0 14330 0 945780 18968 0 28716216 0 14581 0 962346 19137 0 28972082 0 14531 0 959046 19180 0 29037184 0 14465 0 954690 19095 0 28908494 0 14514 0 957924 19095 0 28908494 0 14403 0 950598 19095 0 28908494 0 14493 0 956538 19052 0 28843392 0 14544 0 959904 19095 0 28908494 0 14546 0 960036 19095 0 28908494 0 14558 0 960828 19095 0 28908494 0 14559 0 960894 19053 0 28844906 0 14597 0 963402 19094 0 28906980 0 14509 0 957594 19053 0 28844906 0 14527 0 958782 19137 0 28972082 0 14576 0 962016 19139 0 28973936 0 14575 0 961950 19096 0 28908494 0 14578 0 962148 19052 0 28843392 0 14519 0 958254 18968 0 28716216 0 14579 0 962214 19052 0 28843392 0 14533 0 959178 19095 0 28908494 0 14588 0 962808 19137 0 28972082 0 14503 0 957198 19053 0 28844906 0 14580 0 962280 19095 0 28908494 0 14479 0 955614 18968 0 28716216 0 14477 0 955482 19052 0 28843392 0 14618 0 964788 19137 0 28972082 0 14569 0 961554 19053 0 28844906 0 14586 0 962676 19095 0 28908494 0 4462 0 294492 5438 0 8224172 0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "netstat 1" with liondmask on a 2ms = RTT connection =3D=3D=3D=3D root@stinky 17# netstat 1 input (Total) output packets errs bytes packets errs bytes colls 2 0 132 2 0 0 0 3908 0 258086 7004 0 10856439 0 29353 0 1937298 51940 0 78631282 0 29317 0 1934922 51911 0 78629768 0 29344 0 1936704 51894 0 78502592 0 29340 0 1936440 51841 0 78501078 0 29298 0 1933668 51860 0 78567694 0 29376 0 1938816 51947 0 78629768 0 29344 0 1936704 51928 0 78566180 0 20988 0 1385208 37580 0 56660114 0 19687 0 1299336 35473 0 53704786 0 19705 0 1300530 35431 0 53641198 0 19705 0 1300530 35431 0 53641198 0 19670 0 1298220 35346 0 53512508 0 19680 0 1298880 35388 0 53576096 0 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 02:14:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A90137B401 for ; Mon, 21 Apr 2003 02:14:19 -0700 (PDT) Received: from mail.droso.net (koala.droso.net [193.162.142.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A7D343F93 for ; Mon, 21 Apr 2003 02:14:18 -0700 (PDT) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 15D3032D17; Mon, 21 Apr 2003 11:14:17 +0200 (CEST) Date: Mon, 21 Apr 2003 11:14:16 +0200 From: Erwin Lansing To: Brian Dean Message-ID: <20030421091416.GD86753@droso.net> References: <20030420233133.GA593@neutrino.bsdhome.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20030420233133.GA593@neutrino.bsdhome.com> X-Operating-System: FreeBSD/i386 4.8-RC User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: using x11 forwarding with ssh from a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 09:14:19 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 20, 2003 at 07:31:33PM -0400, Brian Dean wrote: > Hi, Howdy, >=20 > Is anyone having problems connecting to their X server from inside a > jail using ssh's X11 forwarding? >=20 > >From my non-jail environment, I ssh into my jail environment with X11 > forwarding enabled. When I try to invoke an X application, I get: >=20 > % xclock > X11 connection rejected because of wrong authentication. > X connection to localhost:11.0 broken (explicit kill or server shutdown= ). >=20 > It works fine if I uset 'xhost +' in my non-jail environment and the > point my display appropriately from inside the jail (bypassing ssh x11 > forwarding). Any ideas why X11 forwarding doesn't seem to do the > right thing? >=20 This has probably something to do with the mapping of localhost to the external ip address of the jail. Try setting: X11UseLocalhost no in /etc/ssh/sshd_config in your jail should fix this. Cheers, -erwin --=20 _._ _,-'""`-._ Erwin Lansing (,-.`._,'( |\`-/| http://droso.org/ erwin@lansing.dk `-.-' \ )-`( , o o) http://fnidder.dk/ -bf- `- \`_`"'- --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+o7Zoqy9aWxUlaZARApnrAKD5K2U9XhZbshMWp79RljStAd4W4wCg50P7 4pRX64tOs2MPz0ejjtH84tg= =GACu -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 02:24:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C0AB37B401; Mon, 21 Apr 2003 02:24:32 -0700 (PDT) Received: from samson.dc.luth.se (samson.dc.luth.se [130.240.112.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABCD343FD7; Mon, 21 Apr 2003 02:24:30 -0700 (PDT) (envelope-from bj@dc.luth.se) Received: from dc.luth.se (root@bompe.dc.luth.se [130.240.60.42]) by samson.dc.luth.se (8.12.5/8.12.5) with ESMTP id h3L9OTLG010830; Mon, 21 Apr 2003 11:24:29 +0200 (MET DST) Received: from bompe.dc.luth.se (bj@localhost.dc.luth.se [127.0.0.1]) by dc.luth.se (8.12.6/8.11.3) with ESMTP id h3L9OT2F032404; Mon, 21 Apr 2003 11:24:29 +0200 (CEST) (envelope-from bj@bompe.dc.luth.se) Message-Id: <200304210924.h3L9OT2F032404@dc.luth.se> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Jin Guojun [NCS]" In-reply-to: Your message of Mon, 21 Apr 2003 10:27:59 +0200. <200304210827.h3L8Rx2F032265@dc.luth.se> Dcc: From: Borje Josefsson X-Disposition-notification-to: Borje.Josefsson@dc.luth.se X-uri: http://www.dc.luth.se/~bj/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Apr 2003 11:24:29 +0200 Sender: bj@dc.luth.se cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bj@dc.luth.se List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 09:24:32 -0000 On Mon, 21 Apr 2003 10:27:59 +0200 Borje Josefsson wrote: > This patch definitively works, and gives much higher PPS (32000 > instead of 19000). This is on a low-end system (PIII 900MHz with > 33MHz bus), I'll test one of my larger systems later today. = OK. I have now tested on a larger system. Result is better than without the patch, but *not* as good as (for = example) NetBSD or Linux. Value Before patch After patch NetBSD Mbit/sec 617 838 921 PPS (MTU=3D4470) 20000 27500 28000 The problem is (still) that I run out of CPU on the FreeBSD *sender*. Thi= s = doesn't happen on NetBSD (same hardware). The hardware is Xeon 2,8GHz, = PCI-X bus, connected directly to the core routers of a 10 Gbps network. = RTT=3D21 ms, MTU=3D4470. OS=3DFreeBSD 4.8RC with Your patch applied. wilma % vmstat 1 (edited to shorten lines) memory page faults cpu avm fre flt re pi po fr sr in sy cs us sy id 8608 977836 4 0 0 0 0 0 233 20 7 0 2 98 12192 977836 4 0 0 0 0 0 237 59 16 0 1 99 12192 977836 4 0 0 0 0 0 233 20 8 0 2 98 12636 977608 78 0 0 0 7 0 2377 870 241 0 28 72 12636 977608 4 0 0 0 0 0 6522 1834 19 0 100 0 12636 977608 4 0 0 0 0 0 6531 1816 19 0 100 0 12636 977608 4 0 0 0 0 0 6499 1827 19 0 100 0 12636 977608 4 0 0 0 0 0 6575 1821 21 0 100 0 13044 977608 6 0 0 0 0 0 6611 1825 21 0 100 0 top(1) shows: CPU states: 0.0% user, 0.0% nice, 93.4% system, 6.6% interrupt, 0.0% = idle Mem: 6136K Active, 8920K Inact, 34M Wired, 64K Cache, 9600K Buf, 954M Fre= e Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 215 root 43 0 1024K 652K RUN 0:11 92.37% 39.11% ttcp Compare that to when I use NetBSD as sender: CPU states: 0.0% user, 0.0% nice, 6.5% system, 5.5% interrupt, 88.1% = idle Memory: 39M Act, 12K Inact, 628K Wired, 2688K Exec, 5488K File, 399M Free= Swap: 1025M Total, 1025M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 17938 root 2 0 204K 688K netio 0:00 7.80% 1.42% ttcp = The "slow ramping" effect that I described in my earlier letter is not at= = all as visible here, so that might be something else (my small test syste= m = has some switches between itself and the core). bge0 in bge0 out total in total out = packets errs packets errs colls packets errs packets errs colls 6 0 4 0 0 7 0 4 0 0 18364 0 12525 0 0 18364 0 12525 0 0 27664 0 18861 0 0 27665 0 18861 0 0 27511 0 18749 0 0 27511 0 18749 0 0 27281 0 18572 0 0 27282 0 18572 0 0 Net result: Much better, but not as good as the "competitors"... --B=F6rje From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 03:10:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8361837B405 for ; Mon, 21 Apr 2003 03:10:43 -0700 (PDT) Received: from mail59.fg.online.no (mail59-s.fg.online.no [148.122.161.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F84843FE1 for ; Mon, 21 Apr 2003 03:10:42 -0700 (PDT) (envelope-from jarknut@online.no) Received: from default (ti121210a000-0123.dialup.online.no [130.67.95.123]) by mail59.fg.online.no (8.9.3p2/8.9.3) with ESMTP id MAA13128 for ; Mon, 21 Apr 2003 12:10:32 +0200 (MEST) Message-ID: <4115-22003412110457850@default> From: "" To: freebsd-hackers@freebsd.org Date: Mon, 21 Apr 2003 12:05:01 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: IMPORTANT UFO JOB "candy crea cola coffe cinema cracker" c-alfabet X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 10:10:44 -0000 =20 I am just 1 worker, so i need "postmen" Help =2Esend to 99 contries =20= To orgs etc=2E global !progression,!given of our 2 x sun planet friends! Hate is a childish "virus"=2E aggression\treat is illegal Avoid war: never be angry,(its warfare) envy,blame=20 In the irrational hate,mr revenge plays a key role This feeling-mess people take serious and it makes eternal global detours !=2E Deep primitive hate have no end ,just like love It contains intence refuse and condemnation=2Edarkness no end Those who hate therebye dont know of the good things of a person Its the most stupid feeling of all=2Eresults eternal revenge in war Hate creates a limited world and lets fantasi and random def of old incide= nts =20 again and again used to rule=2E (heartless)=20 So that hate therebye also creates incanety is no surprise=2E(brain) intr vare karma pkgcmr mr=2E easy! Get red of the hate on your human "PC" www=2Esilva =20 I am just 1 worker on projekts, so i need the help of "postmen"=20 Help =2Esend this to newspaper=B4s : and radio=B4s? :-) =20 Think global !progression!given of our 4xsun planet friends! Hate is a childish "virus"=2E aggression\treat is illegal Avoid war: never be angry,envy,blame hate revenge etc In the irrational hate,mr revenge plays a key role This feeling-mess people take serious and it makes eternal global detours !=2E Deep primitive hate have no end ,just like love It contains intence refuse and condemnation=2Edarkness no end Those who hate therebye dont know of the good things of a person Its the most stupid feeling of all=2Eresults eternal revenge in war Hate creates a limited world and lets fantasi and random def of old incide= nts =20 again and again used to rule=2E (heartless)=20 So that hate therebye also creates incanety is no surprise=2E(brain) intr vare karma p1r mr=2E easy! Get red of the hate on your human "PC" www=2Esilva =20 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 03:49:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0254137B401; Mon, 21 Apr 2003 03:49:50 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8948943F85; Mon, 21 Apr 2003 03:49:48 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3LAnkC2077910; Mon, 21 Apr 2003 14:49:46 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3LAnkAG077909; Mon, 21 Apr 2003 14:49:46 +0400 (MSD) Date: Mon, 21 Apr 2003 14:49:46 +0400 From: Alex Semenyaka To: Doug Barton Message-ID: <20030421104946.GA77853@snark.ratmir.ru> References: <20030419062121.GA70121@snark.ratmir.ru> <20030420140851.H631@znfgre.tberna.bet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420140851.H631@znfgre.tberna.bet> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: freebsd-gnats-submit@freebsd.org cc: Alex Semenyaka cc: freebsd-stable@freebsd.org Subject: Re: bin/51148 Slow vipw and fast pwd_mkdb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 10:49:50 -0000 Hi, On Sun, Apr 20, 2003 at 02:11:34PM -0700, Doug Barton wrote: > Having been in a "mondo huge master.passwd file" situation myself, my > comment is that people in this situation should probably not be relying on > tools like vipw to manage their stuff. Actually, there is a such corporative policy in the ISP I've taken that huge master.passwd for the test. The main ideas: 1) no automatic changes in the master.passwd 2) time to time visual check and fix of users' data in master.passwd (heh, column from 'master.passwd's). May be good, may be bad, but it exists. > However, my feelings aren't strong > enough to prompt me to close your PR, so good luck. :) Thanks :) SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 04:05:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CDEF37B408 for ; Mon, 21 Apr 2003 04:05:56 -0700 (PDT) Received: from foem.leiden.webweaving.org (fia224-72.dsl.hccnet.nl [62.251.72.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30A2B43F75 for ; Mon, 21 Apr 2003 04:05:53 -0700 (PDT) (envelope-from dirkx@webweaving.org) Received: from foem (foem [10.11.0.2])h3LB5qAf033040 for ; Mon, 21 Apr 2003 13:05:52 +0200 (CEST) (envelope-from dirkx@webweaving.org) Date: Mon, 21 Apr 2003 13:05:52 +0200 (CEST) From: Dirk-Willem van Gulik X-X-Sender: dirkx@foem.leiden.webweaving.org To: freebsd-hackers@freebsd.org Message-ID: <20030421130029.A29555-100000@foem.leiden.webweaving.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: wi(4) - polling(4) changes / DEVICE_POLLING X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 11:05:57 -0000 Is anyone actively working on making the polling(8) to the wi(4) driver ? As in www.wirelessleiden.nl we're seeing very significant (>80%) INTR time spend when doing simple bridging from one wi(4) card to another on the lower end motherboards (P1, slow P2's). And we have similarly seen that using DEVICE_POLLING on the sis(4) cards in the same device would instantly drop sis0<->sis1 INTR time resources to acceptible levels (and increase performance by almost a 2 fold). Or are there any fundamental issues with making wi(4) polling(4) aware ? I.e. some specific firmware issues, etc ? Thanks ! Dw From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 04:07:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA94137B404 for ; Mon, 21 Apr 2003 04:07:09 -0700 (PDT) Received: from saturn.bsdhome.com (rrcs-midsouth-24-199-212-224.biz.rr.com [24.199.212.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id C04B843FAF for ; Mon, 21 Apr 2003 04:07:08 -0700 (PDT) (envelope-from bsd@bsdhome.com) Received: from neutrino.bsdhome.com (jupiter [192.168.220.13]) by saturn.bsdhome.com (8.12.9/8.12.9) with ESMTP id h3LB6xam002948; Mon, 21 Apr 2003 07:06:59 -0400 (EDT) (envelope-from bsd@bsdhome.com) Received: from neutrino.bsdhome.com (localhost [127.0.0.1]) by neutrino.bsdhome.com (8.12.9/8.12.9) with ESMTP id h3LB72Pv089296; Mon, 21 Apr 2003 07:07:02 -0400 (EDT) (envelope-from bsd@neutrino.bsdhome.com) Received: (from bsd@localhost) by neutrino.bsdhome.com (8.12.9/8.12.9/Submit) id h3LB71cZ089295; Mon, 21 Apr 2003 07:07:01 -0400 (EDT) (envelope-from bsd) Date: Mon, 21 Apr 2003 07:07:01 -0400 From: Brian Dean To: Erwin Lansing Message-ID: <20030421110701.GA7959@neutrino.bsdhome.com> References: <20030420233133.GA593@neutrino.bsdhome.com> <20030421091416.GD86753@droso.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030421091416.GD86753@droso.net> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: using x11 forwarding with ssh from a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 11:07:10 -0000 On Mon, Apr 21, 2003 at 11:14:16AM +0200, Erwin Lansing wrote: > X11UseLocalhost no That was it. Thanks! Cheers, -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com http://www.bsdhome.com/ http://www.bdmicro.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 04:17:13 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0D0A37B401 for ; Mon, 21 Apr 2003 04:17:13 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 6972543FBF for ; Mon, 21 Apr 2003 04:17:12 -0700 (PDT) (envelope-from mdcki@gmx.net) Received: (qmail 16642 invoked by uid 65534); 21 Apr 2003 11:17:10 -0000 Received: from cvpn016.gwdg.de (EHLO gmx.net) (134.76.22.16) by mail.gmx.net (mp005-rz3) with SMTP; 21 Apr 2003 13:17:10 +0200 Message-ID: <3EA3D377.2080500@gmx.net> Date: Mon, 21 Apr 2003 13:18:15 +0200 From: Marcin Dalecki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030419 X-Accept-Language: en-us, en, pl, ru MIME-Version: 1.0 To: Martin Blapp References: <20030418132152.X6156@cvs.imp.ch> In-Reply-To: <20030418132152.X6156@cvs.imp.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: imp@imp.com Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 11:17:13 -0000 Martin Blapp wrote: > Hi all, > > Already promised a few times, now I have done it :) > > Many of you may have a laptop and already had it a few times > happen that the new IP didn't got set automatically. So you > had to kill dhclient and restart it again. > > I've added code to dhclient to exactly fix this issue. Now dhclient > behaves now like the win2000 dhcp-client. > > It polls the interface status of the selected interfaces and > sends only requests if the link is there. It cancels all outstanding > requests if the link goes away. The polling is currently hardcoded > and done all 5 seconds. Of course I can change that later and make a > option. Tested on 5.0-current - works as expected. I would consider this options *vital* and would be glad to see it committed it to CURRENT better sooner then later. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 04:34:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CF2B37B401 for ; Mon, 21 Apr 2003 04:34:01 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29ADA43FD7 for ; Mon, 21 Apr 2003 04:34:00 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3LBXvVh061866; Mon, 21 Apr 2003 13:33:57 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Mon, 21 Apr 2003 13:33:57 +0200 (CEST) From: Martin Blapp To: Marcin Dalecki In-Reply-To: <3EA3D377.2080500@gmx.net> Message-ID: <20030421133145.W95995@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <3EA3D377.2080500@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 11:34:01 -0000 Hi, > Tested on 5.0-current - works as expected. I would consider this > options *vital* and would be glad to see it committed it to CURRENT > better sooner then later. Thanks! Thank you for testing. I already sent the patch to the dhclient mailinglist for review. I expect that this patch and several others will be committed directly to the ISC repo. We can then import a fresh version of dhclient. Infact, I'd like to do this with all patches - get them approved from the dhclient people first and then import only the new dhclient version. That makes our live easier ;-) Martin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 04:39:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAC4F37B401 for ; Mon, 21 Apr 2003 04:39:47 -0700 (PDT) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id CDD1D43FBD for ; Mon, 21 Apr 2003 04:39:42 -0700 (PDT) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 38557 invoked by uid 1500); 21 Apr 2003 11:39:38 -0000 Date: Mon, 21 Apr 2003 07:39:38 -0400 From: "Kevin A. Pieckiel" To: Terry Lambert Message-ID: <20030421113938.GA31530@pacer.dmz.smartrafficenter.org> References: <20030420210118.GA21255@pacer.dmz.smartrafficenter.org> <3EA32ADA.CC05B003@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <3EA32ADA.CC05B003@mindspring.com> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org Subject: Re: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 11:39:47 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 20, 2003 at 04:18:50PM -0700, Terry Lambert wrote: > "Kevin A. Pieckiel" wrote: > > First, do open sockets (inet or unix) or pipes (via pipe(2)) count > > against kern.maxfiles, kern.maxfilesperproc, and other related limits? >=20 > Yes. And the limits are not runtime settable. >=20 > > Second, are there sysctl variables that indicate the size or usage > > of the file table? Or is this simply indicated by maxfiles (and > > perhaps others)? Or is there a program that will report this info? >=20 > The "lsof" program will report open files. The "maxfiles" variable > is a limit. The limit is runtime for files, boot time for sockets. Thank you, Terry, for your reply. This is interesting. This obviously shows my ignorance on how this is handled in the kernel, but how is it that one (files) is set at runtime while the other (sockets, pipes) is set at boot time only? These apparently don't use the same mechanism in the kernel to keep up with file descriptors attached to a socket vs those attached to a file. How does one tweak these boot time values? -OR- If this is documented somewhere (I wasn't able to find any docs on this), I don't mind doing some reading to learn this (save for becoming intimate with the kernel code that handles this stuf--that's a little much for the time being). Again, thank you. Kevin Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+o9h5c3iJbvFgTpIRAj3kAJ9tJ9X2/nGOJOJ4PbUq4pHTLb4EawCfYe5y /k9TqYIzCFQk0hqEYiIfFRU= =VbGy -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 06:22:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 651ED37B401 for ; Mon, 21 Apr 2003 06:22:52 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02BCD43FDD for ; Mon, 21 Apr 2003 06:22:51 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h3LDOpxS052610; Mon, 21 Apr 2003 09:24:51 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h3LDOooQ052609; Mon, 21 Apr 2003 09:24:50 -0400 (EDT) Date: Mon, 21 Apr 2003 09:24:49 -0400 From: Jake Burkholder To: Marcel Moolenaar Message-ID: <20030421132449.GA50754@locore.ca> References: <20030421055332.GA4680@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030421055332.GA4680@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org Subject: Re: Is pmap_kextract() allowed to fault? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 13:22:52 -0000 Apparently, On Sun, Apr 20, 2003 at 10:53:32PM -0700, Marcel Moolenaar said words to the effect of; > Gang, > > On ia64 pmap_kextract() uses the tpa instruction which given a > virtual address returns the physical address based on the > translation registers and cache (ie TLB). This can fault when > there's currently no mapping for the virtual address. > > Since all other architectures have a non-faulting implementation > (AFAICT), I'm a bit worried that we might get into trouble on > ia64. I couldn't find anything about pmap_kextract(), so maybe > anybody can enlighten me: > > 1. Is pmap_kextract() allowed to fault? It depends what kind of fault. Will tpa fail if it causes a tlb fault and the page is not in the vhpt (or whatever the fault handler searches), or will it end up calling vm_fault and actually trying to fault in the page? pmap_extract/pmap_kextract are supposed to fail if the page is not mapped by the pmap. > 2. Is pmap_kextract() used often enough that using the cpu's TLB > is a possible performance speedup even if there are costly faults > that can sometimes happen? I doubt it. Jake From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 06:43:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E726C37B401 for ; Mon, 21 Apr 2003 06:43:13 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCCEE43FB1 for ; Mon, 21 Apr 2003 06:43:12 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 520894D; Mon, 21 Apr 2003 08:43:12 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id A499C78C66; Mon, 21 Apr 2003 08:43:11 -0500 (CDT) Date: Mon, 21 Apr 2003 08:43:11 -0500 From: "Jacques A. Vidrine" To: cjclark@alum.mit.edu Message-ID: <20030421134311.GD61593@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , cjclark@alum.mit.edu, Lars Eggert , freebsd-hackers@FreeBSD.org References: <20030410161511.GA25681@madman.celabo.org> <20030416052335.GA2519@blossom.cjclark.org> <20030416123621.GC72501@madman.celabo.org> <20030420165538.GA31101@madman.celabo.org> <3EA2D6F5.4060209@isi.edu> <20030420232614.GA41554@madman.celabo.org> <20030421010025.GB99917@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030421010025.GB99917@blossom.cjclark.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-hackers@FreeBSD.org cc: Lars Eggert Subject: Re: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 13:43:14 -0000 On Sun, Apr 20, 2003 at 06:00:25PM -0700, Crist J. Clark wrote: > It's easy to see what's going on in ESP when you define the encryption > algorithm as the NULL algorithm. Ah, good idea. Why didn't I think of that? :-) > Although I admit it took me a while > to figure out that NULL encryption in the setkey(8) syntax is the > "simple" algorithm. > > In fact, would anyone object to, > > Index: setkey.8 > =================================================================== > RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/setkey.8,v > retrieving revision 1.24 > diff -u -r1.24 setkey.8 > --- setkey.8 1 Jan 2003 18:49:03 -0000 1.24 > +++ setkey.8 21 Apr 2003 00:41:50 -0000 > @@ -563,7 +563,7 @@ > algorithm keylen (bits) comment > des-cbc 64 esp-old: rfc1829, esp: rfc2405 > 3des-cbc 192 rfc2451 > -simple 0 to 2048 rfc2410 > +null-enc 0 to 2048 rfc2410 > blowfish-cbc 40 to 448 rfc2451 > cast128-cbc 40 to 128 rfc2451 > des-deriv 64 ipsec-ciph-des-derived-01 (expired) > Index: token.l > =================================================================== > RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/token.l,v > retrieving revision 1.5 > diff -u -r1.5 token.l > --- token.l 11 Jun 2001 12:39:28 -0000 1.5 > +++ token.l 21 Apr 2003 00:39:41 -0000 > @@ -176,6 +176,7 @@ > {hyphen}E { PREPROC; return(F_ENC); } > des-cbc { PREPROC; yylval.num = SADB_EALG_DESCBC; return(ALG_ENC); } > 3des-cbc { PREPROC; yylval.num = SADB_EALG_3DESCBC; return(ALG_ENC); } > +null-enc { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); } > simple { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); } > blowfish-cbc { PREPROC; yylval.num = SADB_X_EALG_BLOWFISHCBC; return(ALG_ENC); } > cast128-cbc { PREPROC; yylval.num = SADB_X_EALG_CAST128CBC; return(ALG_ENC); } > > The KAME stuff isn't on a vendor branch, not in a contrib/, and not > listed in MAINTAINERS. I guess it's OK to make minor changes/bug fixes > locally? I did file a PR with KAME for this too. Well I wouldn't mind. FWIW, racoon calls it `null_enc' (rather than `simple'). ume & sumikawa appear to be the best folks to treat as maintainers of setkey(8), if anyone. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 06:47:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E5437B401 for ; Mon, 21 Apr 2003 06:47:19 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7720C43F85 for ; Mon, 21 Apr 2003 06:47:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h3LDlIBp098338; Mon, 21 Apr 2003 06:47:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h3LDlHpd098337; Mon, 21 Apr 2003 06:47:17 -0700 (PDT) (envelope-from rizzo) Date: Mon, 21 Apr 2003 06:47:17 -0700 From: Luigi Rizzo To: Dirk-Willem van Gulik Message-ID: <20030421064717.B98117@xorpc.icir.org> References: <20030421130029.A29555-100000@foem.leiden.webweaving.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030421130029.A29555-100000@foem.leiden.webweaving.org>; from dirkx@webweaving.org on Mon, Apr 21, 2003 at 01:05:52PM +0200 cc: freebsd-hackers@freebsd.org Subject: Re: wi(4) - polling(4) changes / DEVICE_POLLING X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 13:47:19 -0000 if i remember well, the "wi" driver copies the packet from the card to the mbuf using programmed I/O. Switching to polling will just move the load under a different bucket (SYSTEM or IDLE instead of INTR) but not change the situation radically, and i doubt you will achieve significant performance improvements. This said i cannot think of issues in making wi polling-aware, as the polling code makes no assumptions on how the device works. cheers luigi On Mon, Apr 21, 2003 at 01:05:52PM +0200, Dirk-Willem van Gulik wrote: > > Is anyone actively working on making the polling(8) to the wi(4) driver ? > > As in www.wirelessleiden.nl we're seeing very significant (>80%) INTR > time spend when doing simple bridging from one wi(4) card to another on > the lower end motherboards (P1, slow P2's). > > And we have similarly seen that using DEVICE_POLLING on the sis(4) cards > in the same device would instantly drop sis0<->sis1 INTR time resources to > acceptible levels (and increase performance by almost a 2 fold). > > Or are there any fundamental issues with making wi(4) polling(4) aware ? > I.e. some specific firmware issues, etc ? > > Thanks ! > > Dw > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 07:39:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DD7B37B401; Mon, 21 Apr 2003 07:39:19 -0700 (PDT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AD8743F3F; Mon, 21 Apr 2003 07:39:18 -0700 (PDT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.12.9/8.12.7) with ESMTP id h3LEdE8s000783; Mon, 21 Apr 2003 23:39:14 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200304211439.h3LEdE8s000783@sana.init-main.com> To: wpaul@freebsd.org Date: Mon, 21 Apr 2003 23:39:14 +0900 From: Takanori Watanabe cc: hackers@freebsd.org Subject: Patch for if_axe to add and to correct ID. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 14:39:19 -0000 Hi Bill, I have yet another ax88172 based USB LAN adapter. And I noticed that the vendor ID you committed is not correct according to the usb.org Website. The ID 0x077b is for LINKSYS, not for ASIX which has ID 0x0b95. The information is at http://www.usb.org/app/pub/dump/comp_dump/ May I commit this patch? Index: if_axe.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/if_axe.c,v retrieving revision 1.2 diff -u -r1.2 if_axe.c --- if_axe.c 20 Apr 2003 20:15:42 -0000 1.2 +++ if_axe.c 21 Apr 2003 03:09:34 -0000 @@ -110,6 +110,7 @@ Static struct axe_type axe_devs[] = { { USB_VENDOR_ASIX, USB_PRODUCT_ASIX_AX88172 }, { USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DUBE100 }, + { USB_VENDOR_LINKSYS2, USB_PRODUCT_LINKSYS_USB200M }, { USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_FA120 }, { 0, 0 } }; Index: usbdevs =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.120 diff -u -r1.120 usbdevs --- usbdevs 20 Apr 2003 20:15:42 -0000 1.120 +++ usbdevs 21 Apr 2003 03:29:30 -0000 @@ -252,7 +252,7 @@ vendor DIGITALSTREAM 0x074e Digital Stream vendor AUREAL 0x0755 Aureal Semiconductor vendor MIDIMAN 0x0763 Midiman -vendor ASIX 0x077b ASIX Electronics +vendor LINKSYS2 0x077b Linksys vendor GRIFFIN 0x077d Griffin Technology vendor SANDISK 0x0781 SanDisk Corp vendor BRIMAX 0x078e Brimax @@ -334,6 +334,7 @@ vendor TODOS 0x0b0c Todos Data System vendor NEC2 0x0b62 NEC vendor ATI2 0x0b6f ATI +vendor ASIX 0x0b95 ASIX Electronics vendor AGATE 0x0c08 Agate Technologies vendor DMI 0x0c0b DMI vendor LUWEN 0x0c76 Luwen @@ -453,7 +454,7 @@ product ASAHIOPTICAL OPTIO230 0x0004 Digital camera /* ASIX Electronics products */ -product ASIX AX88172 0x2226 USB 2.0 10/100 ethernet controller +product ASIX AX88172 0x1720 USB 2.0 10/100 ethernet controller /* ATen products */ product ATEN UC1284 0x2001 Parallel printer adapter @@ -779,6 +780,7 @@ product LINKSYS USB100H1 0x2204 USB100H1 Ethernet/HPNA product LINKSYS USB10TA 0x2206 USB10TA Ethernet product LINKSYS USB10TX2 0x400b USB10TX +product LINKSYS USB200M 0x2226 USB 2.0 10/100 ethernet controller /* Logitech products */ product LOGITECH M2452 0x0203 M2452 keyboard From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 08:26:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11FFE37B404 for ; Mon, 21 Apr 2003 08:26:28 -0700 (PDT) Received: from foem.leiden.webweaving.org (fia224-72.dsl.hccnet.nl [62.251.72.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1391543FE9 for ; Mon, 21 Apr 2003 08:26:24 -0700 (PDT) (envelope-from dirkx@webweaving.org) Received: from foem (foem [10.11.0.2])h3LFQMAf019223 for ; Mon, 21 Apr 2003 17:26:22 +0200 (CEST) (envelope-from dirkx@webweaving.org) Date: Mon, 21 Apr 2003 17:26:22 +0200 (CEST) From: Dirk-Willem van Gulik X-X-Sender: dirkx@foem.leiden.webweaving.org To: freebsd-hackers@freebsd.org Message-ID: <20030421171312.O29555-100000@foem.leiden.webweaving.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: broken buildworld - invalid BFD target X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 15:26:28 -0000 During a normal buildworld of a freshly cvsupped system: cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DHAVE_CONFIG_H -Dyylval=pcap_lval -I/usr/src/lib/libpcap -I. -DINET6 -g -ggdb -I/usr/src/lib/libpcap/../../contrib/libpcap -c /usr/src/contrib/libpcap/pcap.c -o pcap.So ld: invalid BFD target `-o' is this a well known case of breakage ? Dw From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 10:23:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id F365937B401; Mon, 21 Apr 2003 10:23:52 -0700 (PDT) In-Reply-To: <200304211439.h3LEdE8s000783@sana.init-main.com> from Takanori Watanabe at "Apr 21, 2003 11:39:14 pm" To: takawata@init-main.com (Takanori Watanabe) Date: Mon, 21 Apr 2003 10:23: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: <20030421172352.F365937B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: hackers@FreeBSD.ORG Subject: Re: Patch for if_axe to add and to correct ID. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 17:23:53 -0000 > Hi Bill, > > I have yet another ax88172 based USB LAN adapter. > And I noticed that the vendor ID you committed > is not correct according to the usb.org Website. > The ID 0x077b is for LINKSYS, not for ASIX which has ID 0x0b95. > The information is at > http://www.usb.org/app/pub/dump/comp_dump/ > > May I commit this patch? [snip] Looks ok, go for it. And thanks for checking up on this for me. (I got confused when I saw that there was already a vendor entry for Linksys. Why they need two vendor codes I have no idea.) -Bill ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." ============================================================================= From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 10:26:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B7B37B401; Mon, 21 Apr 2003 10:26:28 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9837043F85; Mon, 21 Apr 2003 10:26:27 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0061.cvx22-bradley.dialup.earthlink.net ([209.179.198.61] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197f3d-0002kH-00; Mon, 21 Apr 2003 10:26:22 -0700 Message-ID: <3EA4296B.ACCD9AC8@mindspring.com> Date: Mon, 21 Apr 2003 10:24:59 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: bj@dc.luth.se References: <200304210827.h3L8Rx2F032265@dc.luth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42f8eb4703b79c4256e711cd8da995129a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: "Jin Guojun \[NCS\]" Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 17:26:28 -0000 Borje Josefsson wrote: [ ... Jin Guojun's TCP output patch for high bandwidth delay product ... ] > This patch definitively works, and gives much higher PPS (32000 instead of > 19000). This is on a low-end system (PIII 900MHz with 33MHz bus), I'll > test one of my larger systems later today. > > One question though - is there any way of having the code being more > "aggressive"? As You see, in the netstat output below, it takes ~35 > seconds(!) before reaching full speed. On NetBSD I reach maxPPS almost > immediately. Even if we now (with Your patch) can utilize the hardware > much more, it only helps if You have connections that lasts for a very > long time, so that the "ramping" time is not significant. You can get immediate relief by porting this code instead of using the patch: http://www.psc.edu/networking/tcp.html#psc It is for NetBSD 1.3.2, and includes a SACK, Rate Halving, auto-tuning, and explicit congestion notification: Description: http://www.psc.edu/networking/rate_halving.html Direct link to the code: http://www.psc.edu/networking/ftp/tools/netbsd132_rh_10.tgz Also included is a FACK implementation. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 10:43:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 892FD37B401 for ; Mon, 21 Apr 2003 10:43:14 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 019D843FA3 for ; Mon, 21 Apr 2003 10:43:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0061.cvx22-bradley.dialup.earthlink.net ([209.179.198.61] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197fJs-0006WF-00; Mon, 21 Apr 2003 10:43:09 -0700 Message-ID: <3EA42D52.71BE3533@mindspring.com> Date: Mon, 21 Apr 2003 10:41:38 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dirk-Willem van Gulik References: <20030421130029.A29555-100000@foem.leiden.webweaving.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4632424668222e73f49001c07c5b24410a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: DEVICE_POLLING (was Re: wi(4) - polling(4) changes / DEVICE_POLLING) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 17:43:14 -0000 Dirk-Willem van Gulik wrote: > Is anyone actively working on making the polling(8) to the wi(4) driver ? > > As in www.wirelessleiden.nl we're seeing very significant (>80%) INTR > time spend when doing simple bridging from one wi(4) card to another on > the lower end motherboards (P1, slow P2's). > > And we have similarly seen that using DEVICE_POLLING on the sis(4) cards > in the same device would instantly drop sis0<->sis1 INTR time resources to > acceptible levels (and increase performance by almost a 2 fold). > > Or are there any fundamental issues with making wi(4) polling(4) aware ? > I.e. some specific firmware issues, etc ? It's highly card dependent. I only have one very old card that could not be converted to polling. The reason is that DMA's do not continue to occur to unused ring buffer elements once an interrupt is posted, until that interrupt is acknowledged. If the wi(4) card was too dumb, and did this, then it would have the same problem, and require a firmware update. I doubt this is the case, so a conversion is probably no problem. I did the polling conversion on a couple of the drivers; it was very easy. Having done this conversion, it seems to me that the driver code should be refactored to add *_rxeof and *_txeof, as well as an *_interrupt_able and *_interrupt_pending entry points to the device_method_t array (for this last, see if_sis.c). The entry point *_interrupt_able would enable and disable interrupts, based on its argument. This means there are a couple of drivers that need to be changed to refactor them to look more like Bill Paul's drivers. If this is done, and the polling loop code was made higher-level in common code, rather than being placed in each and every driver, then all future drivers would be "polling safe", automatically. We could also move soft interrupt coelescing to upper level code, as well (for the non-DEVICE_POLLING case). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 11:05:21 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69D9037B404 for ; Mon, 21 Apr 2003 11:05:21 -0700 (PDT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D86243FE3 for ; Mon, 21 Apr 2003 11:05:20 -0700 (PDT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.12.9/8.12.7) with ESMTP id h3LI5F8s002263 for ; Tue, 22 Apr 2003 03:05:16 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200304211805.h3LI5F8s002263@sana.init-main.com> To: hackers@freebsd.org Date: Tue, 22 Apr 2003 03:05:15 +0900 From: Takanori Watanabe Subject: Netgraph Bluetooth stack usage documentation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 18:05:21 -0000 Hi, I bought a pair of USB bluetooth dongle and I managed to make it attach as ng_ubt device by patch below. Then what shall I do next to know whether it works or not? --- /sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c Wed Feb 19 14:47:32 2003 +++ ng_ubt.c Tue Apr 22 02:47:05 2003 @@ -254,6 +254,7 @@ { USB_VENDOR_MSI, USB_PRODUCT_MSI_BT_DONGLE }, { USB_VENDOR_BROADCOM, USB_PRODUCT_DBW_120M_BT_DONGLE }, { USB_VENDOR_EPOX, USB_PRODUCT_BT_DG02_DONGLE }, + { 0x0f4d, 0x1000}, { 0, 0 } }; @@ -396,6 +397,7 @@ USBDEVNAME(sc->sc_dev)); goto bad; } +#if 0 if (id->bInterfaceClass != UICLASS_WIRELESS_CONTROLLER || id->bInterfaceSubClass != UISUBCLASS_RF_CONTROLLER || id->bInterfaceProtocol != UIPROTO_BLUETOOTH) { @@ -406,7 +408,7 @@ id->bInterfaceProtocol); goto bad; } - +#endif for (i = 0; i < id->bNumEndpoints; i ++) { ed = usbd_interface2endpoint_descriptor(sc->sc_iface0, i); if (ed == NULL) { @@ -476,6 +478,7 @@ USBDEVNAME(sc->sc_dev)); goto bad; } +#if 0 if (id->bInterfaceClass != UICLASS_WIRELESS_CONTROLLER || id->bInterfaceSubClass != UISUBCLASS_RF_CONTROLLER || id->bInterfaceProtocol != UIPROTO_BLUETOOTH) { @@ -486,7 +489,7 @@ id->bInterfaceProtocol); goto bad; } - +#endif /* * Scan all alternate configurations for interface 1 */ From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 11:05:45 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47F1137B40A for ; Mon, 21 Apr 2003 11:05:45 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AED143FE1 for ; Mon, 21 Apr 2003 11:05:44 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0061.cvx22-bradley.dialup.earthlink.net ([209.179.198.61] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197ffg-00051G-00; Mon, 21 Apr 2003 11:05:41 -0700 Message-ID: <3EA43297.44FC6E44@mindspring.com> Date: Mon, 21 Apr 2003 11:04:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin A. Pieckiel" References: <20030420210118.GA21255@pacer.dmz.smartrafficenter.org> <3EA32ADA.CC05B003@mindspring.com> <20030421113938.GA31530@pacer.dmz.smartrafficenter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b2058e18f4be6dfb6ef01bd81ebe8e0d93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 18:05:45 -0000 "Kevin A. Pieckiel" wrote: > > The "lsof" program will report open files. The "maxfiles" variable > > is a limit. The limit is runtime for files, boot time for sockets. > > Thank you, Terry, for your reply. > > This is interesting. This obviously shows my ignorance on how this is > handled in the kernel, but how is it that one (files) is set at runtime > while the other (sockets, pipes) is set at boot time only? Things which are allocated by the zone allocator at interrupt time have a fixed amount of KVA that is set at boot time, before the VM system is fully up. Even if it were not fully up, the way it works is by preallocating an address space range to be later filled in by physical pages (you cannot call malloc() at interrupt time, but you can take a fault and fill in a backing page). So the zone size for sockets (inpcb's, tcpcb's) is fixed at boot time, even though it is derived from the "maxfiles". The short answer is "because that's how memory allocation works". In 5.x, the zone limits are still fixed to a static boot-time settable only value -- the same value -- but the actual zone allocations take place later. This is because the new allocator is capable of creating page mappings at interrupt time, as well. The resulting memory is type-stable (meaning once it is allocated, it never changes type), but this makes the competition a little more dynamic: OK for purpose, as long as you do not have initial load spikes not related to the machines primary role. A problem with the 5.x approach is that this means it's possible to get NULL returns from allocation routines, when the system is under memory pressure (because a mapping cannot be established), when certain of those routines are expected to *never* fail to obtain KVA space. Thus you see a lot of people posting about "Trap 12" panics in FreeBSD 5.x which can't happen on 4.x. This is a serious problem, and has yet to be correctly addressed in the new allocator code (the problem occurs because the failure to obtain a mapping occurs before the zone in question hits its administrative limit). Basically, everywhere that calls zalloci() is at risk of panic'ing under heavy load. > These apparently don't use the same mechanism in the kernel to > keep up with file descriptors attached to a socket vs those > attached to a file. Correct. The file descriptors are dynamically allocated; or rather, they are allocated incrementally, as needed, and since this is not at interrupt time, the standard system malloc() can be used. An interesting aside here is that the per process open file table, which holds references to file for the process, is actually allocated at power-of-2, meaning each time it needs to grow, the size is doubled, using realloc(), instead of malloc(), to keep the table allocation contiguous. This means if you use a lot of files, it takes exponentially increasing time to open new files, since realloc has to double the size, and then copy everything. For a few files, this is OK; for 100,000+ files (or network connections) in a single process, this starts to become a real source of overhead. > How does one tweak these boot time values? You add an entry to /boot/loader.conf. Type "man loader.conf" for more information. The name is the same as the sysctl name. > If this is documented somewhere (I wasn't able to find any docs on this), > I don't mind doing some reading to learn this (save for becoming intimate > with the kernel code that handles this stuf--that's a little much for > the time being). It's not well documented. In fact, the "man tuning" manual pages fails to indicate a difference between boot time and run time settings for the value. Most people do not know how zalloci() works, or what values affect the number of objects that are allocated with one allocator or the other. Because of this, you will often see bogus advice, like people telling other people to use sysctl's to modify values that have no effect on what they are actually trying to do, after the boot has been completed. The best way to deal with this is to read and understand the uses of zalloci() vs. zalloc() vs. malloc() in the kernel source code. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 11:33:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6633937B401 for ; Mon, 21 Apr 2003 11:33:24 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7584343FE1 for ; Mon, 21 Apr 2003 11:33:23 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h3LIXNwk092792; Mon, 21 Apr 2003 11:33:23 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h3LIXMT0000738; Mon, 21 Apr 2003 11:33:22 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h3LIXMpm000737; Mon, 21 Apr 2003 11:33:22 -0700 (PDT) Date: Mon, 21 Apr 2003 11:33:22 -0700 From: Marcel Moolenaar To: Jake Burkholder Message-ID: <20030421183322.GA557@dhcp01.pn.xcllnt.net> References: <20030421055332.GA4680@dhcp01.pn.xcllnt.net> <20030421132449.GA50754@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030421132449.GA50754@locore.ca> User-Agent: Mutt/1.5.3i cc: freebsd-hackers@freebsd.org Subject: Re: Is pmap_kextract() allowed to fault? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 18:33:24 -0000 On Mon, Apr 21, 2003 at 09:24:49AM -0400, Jake Burkholder wrote: > Apparently, On Sun, Apr 20, 2003 at 10:53:32PM -0700, > Marcel Moolenaar said words to the effect of; > > > Gang, > > > > On ia64 pmap_kextract() uses the tpa instruction which given a > > virtual address returns the physical address based on the > > translation registers and cache (ie TLB). This can fault when > > there's currently no mapping for the virtual address. > > > > Since all other architectures have a non-faulting implementation > > (AFAICT), I'm a bit worried that we might get into trouble on > > ia64. I couldn't find anything about pmap_kextract(), so maybe > > anybody can enlighten me: > > > > 1. Is pmap_kextract() allowed to fault? > > It depends what kind of fault. Will tpa fail if it causes a tlb fault > and the page is not in the vhpt (or whatever the fault handler searches), > or will it end up calling vm_fault and actually trying to fault in the > page? It will end up calling vm_fault() if so required. > > 2. Is pmap_kextract() used often enough that using the cpu's TLB > > is a possible performance speedup even if there are costly faults > > that can sometimes happen? > > I doubt it. Ok, thanks. I think I'll use a non-trapping implementation then. There's just too much circumstantiality... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 12:20:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB81837B401 for ; Mon, 21 Apr 2003 12:20:03 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F21243FA3 for ; Mon, 21 Apr 2003 12:20:02 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h3LJM5xS054963; Mon, 21 Apr 2003 15:22:05 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h3LJM4C5054962; Mon, 21 Apr 2003 15:22:04 -0400 (EDT) Date: Mon, 21 Apr 2003 15:22:04 -0400 From: Jake Burkholder To: Marcel Moolenaar Message-ID: <20030421192204.GH50754@locore.ca> References: <20030421055332.GA4680@dhcp01.pn.xcllnt.net> <20030421132449.GA50754@locore.ca> <20030421183322.GA557@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030421183322.GA557@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org Subject: Re: Is pmap_kextract() allowed to fault? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 19:20:04 -0000 Apparently, On Mon, Apr 21, 2003 at 11:33:22AM -0700, Marcel Moolenaar said words to the effect of; > On Mon, Apr 21, 2003 at 09:24:49AM -0400, Jake Burkholder wrote: > > Apparently, On Sun, Apr 20, 2003 at 10:53:32PM -0700, > > Marcel Moolenaar said words to the effect of; > > > > > Gang, > > > > > > On ia64 pmap_kextract() uses the tpa instruction which given a > > > virtual address returns the physical address based on the > > > translation registers and cache (ie TLB). This can fault when > > > there's currently no mapping for the virtual address. > > > > > > Since all other architectures have a non-faulting implementation > > > (AFAICT), I'm a bit worried that we might get into trouble on > > > ia64. I couldn't find anything about pmap_kextract(), so maybe > > > anybody can enlighten me: > > > > > > 1. Is pmap_kextract() allowed to fault? > > > > It depends what kind of fault. Will tpa fail if it causes a tlb fault > > and the page is not in the vhpt (or whatever the fault handler searches), > > or will it end up calling vm_fault and actually trying to fault in the > > page? > > It will end up calling vm_fault() if so required. Yes, this is very bad. Especially for things like /dev/kmem, where you want to validate an address passed from userland. Jake > > > > 2. Is pmap_kextract() used often enough that using the cpu's TLB > > > is a possible performance speedup even if there are costly faults > > > that can sometimes happen? > > > > I doubt it. > > Ok, thanks. I think I'll use a non-trapping implementation then. > There's just too much circumstantiality... > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 13:25:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 523C137B401 for ; Mon, 21 Apr 2003 13:25:51 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921F443FD7 for ; Mon, 21 Apr 2003 13:25:50 -0700 (PDT) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-8-62-147-158-16.dial.proxad.net [62.147.158.16]) by postfix4-1.free.fr (Postfix) with SMTP id EC86F1A36B for ; Mon, 21 Apr 2003 22:25:48 +0200 (CEST) Received: (qmail 8048 invoked by uid 1001); 21 Apr 2003 22:39:25 -0000 Date: Mon, 21 Apr 2003 22:39:25 +0000 From: Nicolas Souchu To: Poul-Henning Kamp Message-ID: <20030421223925.B7928@armor.free.fr> References: <20030413223656.A21075@armor.free.fr> <3403.1050272127@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3403.1050272127@critter.freebsd.dk>; from phk@phk.freebsd.dk on Mon, Apr 14, 2003 at 12:15:27AM +0200 cc: hackers@freebsd.org Subject: Re: infinite loop in kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 20:25:51 -0000 On Mon, Apr 14, 2003 at 12:15:27AM +0200, Poul-Henning Kamp wrote: > In message <20030413223656.A21075@armor.free.fr>, Nicolas Souchu writes: > > > >Hi folks, > > > >I'm trying to debug some infinite loop in the kernel. I guess > >this is the problem since key interrupts are still working but > >the system does not respond otherwise. > > > >Unfortunatly, breaking in the debugger only gives my the > >trace of the kbd intr thread... > > > >Which data structure should I check? > > Use "ps" in DDB to see which processes are runnable for instance. Any hint on how to interpret it? The scheduler interrupts are certainly working, I could certainly break in it and see what is being currently scheduled? -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 15:13:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E64537B401 for ; Mon, 21 Apr 2003 15:13:05 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2A5E43FBF for ; Mon, 21 Apr 2003 15:13:01 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3LMCwVh031332; Tue, 22 Apr 2003 00:12:59 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Tue, 22 Apr 2003 00:12:58 +0200 (CEST) From: Martin Blapp To: Alexander Pohoyda In-Reply-To: <20030420171922.Q95995@cvs.imp.ch> Message-ID: <20030422000930.C95995@cvs.imp.ch> References: <20030418132152.X6156@cvs.imp.ch> <20030420014419.T95995@cvs.imp.ch><20030420171922.Q95995@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: [PATCH] dhclient active interface detection patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 22:13:05 -0000 Hi all, Just to note. If you start your laptop without net connection it will hang when dhclient gets started. To prevent/workaround this, you'll have to add the option -nw. Of course one could just skip the autodetection of the interface and proceed anyway. But then the polling is not done and one has still to restart dhclient manually. I added this to the patchset I've made together with two different minor fixes. I beleave that this patch now really works good for all cases. --- etc/rc.d/dhclient.orig Tue Apr 22 00:00:05 2003 +++ etc/rc.d/dhclient Tue Apr 22 00:00:16 2003 @@ -17,7 +17,7 @@ . /etc/network.subr name="dhclient" -command="/sbin/${name}" +command="/sbin/${name} -nw" pidfile="/var/run/${name}.pid" case "${OSTYPE}" in FreeBSD) From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 16:36:31 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B63EC37B401 for ; Mon, 21 Apr 2003 16:36:31 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E733F43FBD for ; Mon, 21 Apr 2003 16:36:30 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3LNaIA7028105; Mon, 21 Apr 2003 17:36:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 21 Apr 2003 17:35:59 -0600 (MDT) Message-Id: <20030421.173559.43009491.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20030421064717.B98117@xorpc.icir.org> References: <20030421130029.A29555-100000@foem.leiden.webweaving.org> <20030421064717.B98117@xorpc.icir.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: wi(4) - polling(4) changes / DEVICE_POLLING X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 23:36:32 -0000 In message: <20030421064717.B98117@xorpc.icir.org> Luigi Rizzo writes: : if i remember well, the "wi" driver copies the packet from the card : to the mbuf using programmed I/O. Switching to polling will just : move the load under a different bucket (SYSTEM or IDLE instead : of INTR) but not change the situation radically, and i : doubt you will achieve significant performance improvements. The wi driver does use PIO to move the data from the cards to memory. Newer PCI and mini-pci cards support using DMA to do this, but there's no support for that in the driver at the moment. The wi cards are just damn expensive to talk to :-(. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 16:39:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56D6C37B401; Mon, 21 Apr 2003 16:39:54 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2153843FBD; Mon, 21 Apr 2003 16:39:52 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3LNdoUE031404; Tue, 22 Apr 2003 02:39:51 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3LNdo57031401; Tue, 22 Apr 2003 02:39:50 +0300 (EEST) Date: Tue, 22 Apr 2003 02:39:50 +0300 (EEST) From: Narvi To: Alex Semenyaka In-Reply-To: <20030420011039.GC52081@snark.ratmir.ru> Message-ID: <20030422023703.G29990-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: /bin/sh and 32-bit arithmetics [CORRECTED] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 23:39:54 -0000 On Sun, 20 Apr 2003, Alex Semenyaka wrote: > 7 5.20 6.37 3.51 22.50% i=$(($i<<1)) > 8 5.25 6.42 3.51 22.27% i=$(($i<<$m)) > > As you can see, even for arithmetic-only script the overhead is not too big > except with one case: shift operation. I decided to investigate is it usual > script operation. I've went through all scripts I could find in my FreeBSD > box. I've searched them with "locate .sh | grep '\.sh$'". There were a lot > of them: > > $ locate .sh | grep '\.sh$' | wc -l > 1637 > > But there was no any script that uses the shift operation. Good, but not > enough. I've take the script that uses arithmetics and do some other job, > ttfadmin.sh from the Abiword package. I've run in 10000 times in the loop > with both (64-bit and 32-bit) shells. As an argument it received empty > directory so no work has been done, just run, check pars, found no files, > exit. It takes 65.35 seconds in the first case and 65.30 second in the second > one. So the the time that arithmetics takes during the real script execution > is too small in comparison to total running time (obviously: arithmetics > is in-core calculations while any script usually run some external programs > etc, and at least I/O is involved). Ahem - wouldn't it be easier to find out *why* the dramatic speed-down happens and trying to combat it as opposed to trying to show the speed-down is not releavant? There shouldn't be anything inherently that much slower in 64 bit shifts... > > Thanks! > > SY, Alex > From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 20:33:57 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C2C937B401; Mon, 21 Apr 2003 20:33:57 -0700 (PDT) Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED9743FB1; Mon, 21 Apr 2003 20:33:55 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) ESMTP id h3M2ZW8l000382; Mon, 21 Apr 2003 19:35:38 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Sender: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net Message-ID: <3EA4AA74.F9993276@lbl.gov> Date: Mon, 21 Apr 2003 19:35:32 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: bj@dc.luth.se References: <200304210827.h3L8Rx2F032265@dc.luth.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: patch for test (Was: tcp_output starving -- is due to mbuf get delay?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 03:33:58 -0000 It is hard to compare your netstat output due to short NetBSD output. In NetBSD, it is too short to know if TCP output has been saturated (reach the maximum packet/sec?) at second 3,it reached 18.6Kpkt/s or 28KB/s, which means MTU = 28KB / 18.5 = 1500, right? The FreeBSD seems did better job, at second 2, it already reached 72KB/s. The pkt/s is low because you had Jumbo frame. The net.inet.tcp.liondmask=7 has doubled your TCP window from 1,314,022 to 2,204,667, which is a fully opened cwnd for 22ms + 1Gb/s path. There is nothing to be better than that. The only thing left to chew your CPU is the memory copy. On my web page, it shows that we have reduced all mbuf chain overhead, but there is still a second memory copy overhead, which is can be also reduced. However, this is no a patch any more. It requires to modify mbuf operation. I am BCC this to core@freebsd.org, but I am not sure it will get throughput. To reduce the second memory copy, the mbuf structure needs to have another flag -- EOP -- end of packet. At this point, in xxx_usr_send(), we can simply copy each t_maxseg to a mbuf chain, and set EOP bit in the mbuf flags, then chain this mbuf into the sb_mb. At the tcp_output(), where I modified the mbuf chain for m_copydata & m_copy, get rid of these two copy routines, and simply hand the m to the if_queue. Since we just pass the handle, when NIC driver passes the mbuf to the m_free, m_free will do nothing for these mbufs since EOP is set. Therefore, we will reduce the mbuf operation on both en_queue and m_free. This will left only one memory copy. For a system with 64-bit PCI chipset, this will not be a bottleneck at all. Of course, we can further reduce this one (to make zero copy TCP). Lock (wire) down the user buffer, and simply assign the user space to the mcluster as E_USR_EXT. This may be completely make sense since future computer will have large memory (at least 1GB), where rarely have some applications write a buffer large than 1MB at once (typically 64KB up to 640KB). So lock down 0.1% of total system memory is not a bad thing. If you want even better, the new TCP (Lion) stack is going for that goal, but it will not be available till it is stabilized. As Terry mentioned, now, you may try to play the NetBSD TCP stack first since you have seen that NetBSD does a better job, and provide some feedback. -Jin Borje Josefsson wrote: > On Sun, 20 Apr 2003 13:12:42 PDT "Jin Guojun [NCS]" wrote: > > > Now the patch is ready. It has been tested on both 4.7 and 4.8. > > For 4.7, one has to manually add an empty line before the comment prior to the > > tcp_output() routine. > comment for beginning the tcp_output() in 4.7-RELEASE :-( > > > > > Some more hints for tracing: (net.inet.tcp.liondmask is a bitmap) > > bit 0-1 (value 1, 2, or 3) is for enabling tcp_output() mbuf chain modification > > bit 2 (value 4) is for enabling sbappend() mbuf chain modification > > bit 3 (value 8) is for tcp_input (DO NOT TRY IT, it is not ready). > > > > bit 9 (value 512) is for enabling check routine (dump errors to /var/log/messag). > > > > If you do have problem, set net.inet.tcp.liondmask to 512 and look what message says. > > If you would like to know which part causing problem or not working properly, > > set net.inet.tcp.liondmask to 1, 2, 3 or 4 to test individual module. > > Thanks!! > > This patch definitively works, and gives much higher PPS (32000 instead of > 19000). This is on a low-end system (PIII 900MHz with 33MHz bus), I'll > test one of my larger systems later today. > > One question though - is there any way of having the code being more > "aggressive"? As You see, in the netstat output below, it takes ~35 > seconds(!) before reaching full speed. On NetBSD I reach maxPPS almost > immediately. Even if we now (with Your patch) can utilize the hardware > much more, it only helps if You have connections that lasts for a very > long time, so that the "ramping" time is not significant. > > *Note* (the very last output below) that this seems to be highly dependant > on RTT. On a 2ms connection (~50 miles) I reach max RTT almost > immediately. (can't explain why I go to 51kpps and then fall back to > 35kpps, this is repeatable). > > Apart from vanilla 4.8R I have set: > > kern.ipc.maxsockbuf=8388608 > net.inet.tcp.sendspace=3217968 > net.inet.tcp.recvspace=3217968 > kern.ipc.nmbclusters=8192 > > And this test is done on a connection with RTT in the order of 22 ms. > > --Börje > > =========== "netstat 1" **on NetBSD** (for comparation) ===== > > bge0 in bge0 out total in total out > packets errs packets errs colls packets errs packets > 1 0 1 0 0 1 0 1 > 7118 0 11315 0 0 7118 0 11315 > 18604 0 28014 0 0 18604 0 28014 > 18610 0 28005 0 0 18611 0 28005 > > (NOTE that this example is using larger MTU, and not on the same hardware > as below, but the behaviour of reaching maxPPS "immediately" is the same) > > =========== "netstat 1" with liondmask=7 ================ > > input (Total) output > packets errs bytes packets errs bytes colls > 6 0 540 3 0 228 0 > 37 0 2712 56 0 72216 0 > 646 0 42636 823 0 1244686 0 > 1548 0 102168 1966 0 2975188 0 > 2432 0 160512 3039 0 4604252 0 > 3301 0 217866 4193 0 6345352 0 > 4174 0 275484 5254 0 7950192 0 > 5011 0 330726 6373 0 9650414 0 > 5836 0 385176 7448 0 11271908 0 > 6675 0 440550 8519 0 12896430 0 > 7528 0 496848 9596 0 14527008 0 > 8408 0 554928 10626 0 16089456 0 > 9212 0 607992 11652 0 17636764 0 > 9962 0 657492 12698 0 19223436 0 > 10699 0 706134 13694 0 20731380 0 > 11368 0 750288 14648 0 22175736 0 > 12144 0 801504 15697 0 23768464 0 > 12802 0 844932 16693 0 25267324 0 > 13412 0 885192 17552 0 26576934 0 > 14001 0 924066 18495 0 28001608 0 > 14444 0 953304 19415 0 29384230 0 > 15041 0 992706 20275 0 30701070 0 > 15681 0 1034946 21327 0 32283200 0 > 16224 0 1070784 22202 0 33610978 0 > 16621 0 1096986 22888 0 34651096 0 > 17050 0 1125300 23568 0 35682130 0 > 17721 0 1169586 24573 0 37200672 0 > 18256 0 1204896 25361 0 38401274 0 > 18782 0 1239612 26128 0 39550400 0 > 19359 0 1277694 26972 0 40834272 0 > 20150 0 1329900 28015 0 42413374 0 > 20900 0 1379400 28962 0 43854702 0 > 21523 0 1420518 30024 0 45447430 0 > 22256 0 1468896 30891 0 46767638 0 > 22882 0 1510212 31655 0 47924334 0 > 23087 0 1523742 31865 0 48243788 0 > 23225 0 1532850 32038 0 48502682 0 > > It seems that I reach the limit about here - 35-36 sec after start > > 23170 0 1529220 32121 0 48629858 0 > 23223 0 1532718 32036 0 48501168 0 > 23200 0 1531200 32121 0 48629858 0 > 23103 0 1524792 32122 0 48631372 0 > 23104 0 1524864 32080 0 48565096 0 > 23214 0 1532124 32079 0 48566270 0 > 23147 0 1527696 32036 0 48501168 0 > 10318 0 680988 13543 0 20495142 0 > 1 0 66 1 0 178 0 > 1 0 66 1 0 178 0 > > =========== "netstat 1" with liondmask=7 ================ > > With plain 4.8 (liondmask=0) I get: > > root@stinky 8# netstat 1 > input (Total) output > packets errs bytes packets errs bytes colls > 7 0 732 10 0 2394 0 > 437 0 28842 556 0 840448 0 > 1343 0 88638 1669 0 2531586 0 > 2201 0 145266 2757 0 4166706 0 > 3082 0 203406 3857 0 5841190 0 > 4021 0 265386 4959 0 7503562 0 > 4877 0 321882 6017 0 9111430 0 > 5621 0 370986 7064 0 10690532 0 > 6471 0 427086 8136 0 12319596 0 > 7216 0 476256 9177 0 13889614 0 > 8006 0 528396 10181 0 15415726 0 > 8725 0 575850 11215 0 16975146 0 > 9482 0 625812 12259 0 18561818 0 > 10205 0 673530 13258 0 20071276 0 > 10846 0 715836 14115 0 21365746 0 > 11563 0 763158 15223 0 23046286 0 > 12399 0 818334 16266 0 24628416 0 > 13024 0 859584 17119 0 25913802 0 > 13609 0 898194 17949 0 27173450 0 > 14316 0 944856 18798 0 28458836 0 > 14391 0 949806 18842 0 28522764 0 > 14463 0 954558 19010 0 28779804 0 > > Here I reach the limit after 20 seconds. > > 14500 0 957000 19095 0 28908494 0 > 14534 0 959244 19053 0 28844906 0 > 14599 0 963534 19052 0 28843392 0 > 14526 0 958716 19053 0 28844906 0 > 14484 0 955944 18967 0 28714702 0 > 14330 0 945780 18968 0 28716216 0 > 14581 0 962346 19137 0 28972082 0 > 14531 0 959046 19180 0 29037184 0 > 14465 0 954690 19095 0 28908494 0 > 14514 0 957924 19095 0 28908494 0 > 14403 0 950598 19095 0 28908494 0 > 14493 0 956538 19052 0 28843392 0 > 14544 0 959904 19095 0 28908494 0 > 14546 0 960036 19095 0 28908494 0 > 14558 0 960828 19095 0 28908494 0 > 14559 0 960894 19053 0 28844906 0 > 14597 0 963402 19094 0 28906980 0 > 14509 0 957594 19053 0 28844906 0 > 14527 0 958782 19137 0 28972082 0 > 14576 0 962016 19139 0 28973936 0 > 14575 0 961950 19096 0 28908494 0 > 14578 0 962148 19052 0 28843392 0 > 14519 0 958254 18968 0 28716216 0 > 14579 0 962214 19052 0 28843392 0 > 14533 0 959178 19095 0 28908494 0 > 14588 0 962808 19137 0 28972082 0 > 14503 0 957198 19053 0 28844906 0 > 14580 0 962280 19095 0 28908494 0 > 14479 0 955614 18968 0 28716216 0 > 14477 0 955482 19052 0 28843392 0 > 14618 0 964788 19137 0 28972082 0 > 14569 0 961554 19053 0 28844906 0 > 14586 0 962676 19095 0 28908494 0 > 4462 0 294492 5438 0 8224172 0 > > ============ "netstat 1" with liondmask on a 2ms RTT connection ==== > > root@stinky 17# netstat 1 > input (Total) output > packets errs bytes packets errs bytes colls > 2 0 132 2 0 0 0 > 3908 0 258086 7004 0 10856439 0 > 29353 0 1937298 51940 0 78631282 0 > 29317 0 1934922 51911 0 78629768 0 > 29344 0 1936704 51894 0 78502592 0 > 29340 0 1936440 51841 0 78501078 0 > 29298 0 1933668 51860 0 78567694 0 > 29376 0 1938816 51947 0 78629768 0 > 29344 0 1936704 51928 0 78566180 0 > 20988 0 1385208 37580 0 56660114 0 > 19687 0 1299336 35473 0 53704786 0 > 19705 0 1300530 35431 0 53641198 0 > 19705 0 1300530 35431 0 53641198 0 > 19670 0 1298220 35346 0 53512508 0 > 19680 0 1298880 35388 0 53576096 0 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 21:53:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF8CD37B401 for ; Mon, 21 Apr 2003 21:53:56 -0700 (PDT) Received: from mail.junkproof.net (mail.junkproof.net [206.55.70.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C31943FCB for ; Mon, 21 Apr 2003 21:53:56 -0700 (PDT) (envelope-from bill@twwells.com) Received: from mail (helo=mail.junkproof.net) by mail.junkproof.net with local-bsmtp (Exim 3.32 #1) id 197pn0-0005io-00 for freebsd-hackers@freebsd.org; Mon, 21 Apr 2003 23:53:54 -0500 X-Filter-Status: ok mail.junkproof.net 6 Received: from bill.twwells.com ( [68.32.144.147] ) by mail.junkproof.net via tcp with submission id 3ea4cadc-14fc17; Mon, 21 Apr 2003 23:53:48 -0500 Received: from bill by bill.twwells.com with local (Exim 4.14) id 197pmo-000CRx-A0; Tue, 22 Apr 2003 00:53:42 -0400 In-Reply-To: <3EA43297.44FC6E44@mindspring.com> To: Terry Lambert Date: Tue, 22 Apr 2003 00:53:42 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: From: Bill Wells cc: freebsd-hackers@freebsd.org Subject: Re: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 04:53:57 -0000 > An interesting aside here is that the per process open file table, > which holds references to file for the process, is actually > allocated at power-of-2, meaning each time it needs to grow, the > size is doubled, using realloc(), instead of malloc(), to keep the > table allocation contiguous. This means if you use a lot of files, > it takes exponentially increasing time to open new files, since > realloc has to double the size, and then copy everything. For a > few files, this is OK; for 100,000+ files (or network connections) > in a single process, this starts to become a real source of overhead. Let's say you just allocated the 9th element. You started out with a table of one element, doubled it (copying 1), doubled it to 4 elements (copying 2 + 1 or 3), thence to 8 (copying 4 + 3 or 7) and finally to 16 (copying 8 + 7 or 15). To allocate then 2**n + 1'th entry, you will have to do 2**(n+1) copies. Thus you will do (2**(n+1) - 1) / (2**n + 1) copies per allocated entry. This is the worst case, since additional allocations up to 2**(n+1) don't incur any additional copies. The upper bound is two entries copied per entry allocated. This makes exponential allocation a *linear time* algorithm. This just isn't a major time cost unless the chunkiness of the time spent is an issue. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 00:04:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54E8637B401 for ; Tue, 22 Apr 2003 00:04:12 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3E5243FAF for ; Tue, 22 Apr 2003 00:04:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0155.cvx21-bradley.dialup.earthlink.net ([209.179.192.155] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197rp3-0002iM-00; Tue, 22 Apr 2003 00:04:10 -0700 Message-ID: <3EA4E91D.16AD8565@mindspring.com> Date: Tue, 22 Apr 2003 00:02:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Wells References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ba16ac8a01ad94978640be6d87fe35a3a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 07:04:12 -0000 Bill Wells wrote: > > An interesting aside here is that the per process open file table, > > which holds references to file for the process, is actually > > allocated at power-of-2, meaning each time it needs to grow, the > > size is doubled, using realloc(), instead of malloc(), to keep the > > table allocation contiguous. This means if you use a lot of files, > > it takes exponentially increasing time to open new files, since > > realloc has to double the size, and then copy everything. For a > > few files, this is OK; for 100,000+ files (or network connections) > > in a single process, this starts to become a real source of overhead. > > Let's say you just allocated the 9th element. You started out with > a table of one element, doubled it (copying 1), doubled it to 4 > elements (copying 2 + 1 or 3), thence to 8 (copying 4 + 3 or 7) > and finally to 16 (copying 8 + 7 or 15). > > To allocate then 2**n + 1'th entry, you will have to do 2**(n+1) > copies. Thus you will do (2**(n+1) - 1) / (2**n + 1) copies per > allocated entry. This is the worst case, since additional > allocations up to 2**(n+1) don't incur any additional copies. > > The upper bound is two entries copied per entry allocated. This > makes exponential allocation a *linear time* algorithm. This just > isn't a major time cost unless the chunkiness of the time spent is > an issue. The copy time goes up as 2^N; the rate of copies required goes up as log2(N). Overall, it's true that the time, scaled linearly against N, and averaged, is a linear increase (e.g. multiply the two, and then treat as a continuous function, even though it's not). But I was more interested in instaneous response. Consider that the latency involved in the copy increases the delay for all other pending operations. For example, on an HTTP server, copying the file results in bursty response. Also realize that if you are under a "flash crowd" situation, this is *exactly* the point in time you *don't* want to increase your response latency, as requests will continue to pile up (e.g. requests as a result of being "slashdotted"). The obvious workaround is to dup2() something like /dev/null to fd 200,000, and grow the table once, up front. Still, it's a pain in the butt that the default algorithm takes more time at exactly the point where you don't have time available. And the "grow it once" approach has the drawback that that memory is now committed to a particular task, when it may turn out to be better utilized elsewhere, until load merits it. It's tempting to come up with a way to register fd's into a kqueue for incoming events, without adding a real per-process open file table entry for them (especiall for sockets), and avoid the overhead altogether. Of course, for something like that, struct fileops must die. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 00:17:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1E7837B401 for ; Tue, 22 Apr 2003 00:17:38 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 2E36143F3F for ; Tue, 22 Apr 2003 00:17:37 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 24975 invoked from network); 22 Apr 2003 07:12:05 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 22 Apr 2003 07:12:05 -0000 Received: (qmail 7964 invoked by uid 1000); 22 Apr 2003 07:15:23 -0000 Date: Tue, 22 Apr 2003 10:15:22 +0300 From: Peter Pentchev To: Friedemann Becker Message-ID: <20030422071522.GA542@straylight.oblivion.bg> Mail-Followup-To: Friedemann Becker , freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: blocking nfs call X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 07:17:39 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 19, 2003 at 10:56:39PM +0200, Friedemann Becker wrote: > I tried to mount /usr/src /usr/obj and /usr/gnats from my home machine > on a remote computer, it is a router that hangs on reboot and I have > no time to get there soon, so I have to solve it per ssh. >=20 > The problem is, the calls in mount and umount seem to be blocking > calls, and when something goes wrong (appearently it did ;-), > mount/umount does never return and can't be killed. > this is the ps ax output of the dead processes The 'soft' and 'intr' mount options might help. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wou= ldn't be false. --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+pOwJ7Ri2jRYZRVMRApsQAKCg7cWiOdjsuGhuFGqClv4YilEpvgCfYrGa cmlRGc0Bi5ybrXJ0z+42TUU= =Y88T -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 06:03:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5530C37B401 for ; Tue, 22 Apr 2003 06:03:55 -0700 (PDT) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2B0543FA3 for ; Tue, 22 Apr 2003 06:03:53 -0700 (PDT) (envelope-from marcelo-leal@procergs.rs.gov.br) Received: from ws-tor-0004.procergs (unknown [172.28.5.20]) by honolulu.procergs.com.br (Postfix) with ESMTP id CBEDEAAB6 for ; Tue, 22 Apr 2003 10:03:50 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id BC1461030E; Tue, 22 Apr 2003 10:03:49 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id 5B5D61030D for ; Tue, 22 Apr 2003 10:03:49 -0300 (BRT) From: omestre@freeshell.org To: freebsd-hackers@freebsd.org Date: Tue, 22 Apr 2003 10:03:44 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030422130349.BC1461030E@ws-tor-0004.procergs> Subject: nfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 13:03:55 -0000 Have the FreeBSD 5.0 problems with NFS locking? I have some diskless machines that are not working. (In 4.x work fine). Thanks! --- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 07:45:31 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EB2A37B401; Tue, 22 Apr 2003 07:45:31 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2639643FBD; Tue, 22 Apr 2003 07:45:30 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3MEjRC2005098; Tue, 22 Apr 2003 18:45:28 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3MEjRcx005097; Tue, 22 Apr 2003 18:45:27 +0400 (MSD) Date: Tue, 22 Apr 2003 18:45:26 +0400 From: Alex Semenyaka To: Narvi Message-ID: <20030422144526.GD4968@snark.ratmir.ru> References: <20030420011039.GC52081@snark.ratmir.ru> <20030422023703.G29990-100000@haldjas.folklore.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030422023703.G29990-100000@haldjas.folklore.ee> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: freebsd-current@freebsd.org cc: Alex Semenyaka Subject: Re: /bin/sh and 32-bit arithmetics [CORRECTED] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 14:45:32 -0000 On Tue, Apr 22, 2003 at 02:39:50AM +0300, Narvi wrote: > Ahem - wouldn't it be easier to find out *why* the dramatic speed-down > happens and trying to combat it as opposed to trying to show the > speed-down is not releavant? There shouldn't be anything inherently that > much slower in 64 bit shifts... One again: that speed-down is the effect of the disk operations which are slower than in-core arithmetics in the ORDERS of magnitude. When you run any external program from the disk those operations are _always_ included. My point was: since any real script executes at least several external programs the total time it runs will not be affected with the substitution of 32-bit arithmetucs to 64-bit one, even when overflow checks are enabled. I am not concerning about the speed of the external application running, for I am solving the absolutely different problem now. SY, Alex From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 08:55:57 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3716E37B404 for ; Tue, 22 Apr 2003 08:55:57 -0700 (PDT) Received: from accms33.physik.rwth-aachen.de (accms33.physik.RWTH-Aachen.DE [137.226.46.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3D5643FE0 for ; Tue, 22 Apr 2003 08:55:55 -0700 (PDT) (envelope-from kuku@accms33.physik.rwth-aachen.de) Received: (from kuku@localhost) by accms33.physik.rwth-aachen.de (8.11.6/8.9.3) id h3MFtsJ11124 for hackers@freebsd.org; Tue, 22 Apr 2003 17:55:54 +0200 Date: Tue, 22 Apr 2003 17:55:54 +0200 From: Christoph Kukulies Message-Id: <200304221555.h3MFtsJ11124@accms33.physik.rwth-aachen.de> To: hackers@freebsd.org Subject: DE203 (le0) - strange bus crosstalk? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 15:55:57 -0000 I have a DEC 203 lance (ISA) card in a 5.0R server and I recently received a fix from the driver author that enabled the driver again under 5.0. I'm now observing a very strange behaviour under X11 that went away immediately after I took out the card of the system. With the card in place and a serial mouse at /dev/ttyd0 or /dev/cuaa0 moving the mouse caused pixels arbitrarily being set on the screen. Moreover scrolling a window in the webbroswer caused the browser contents foobared (f*cked up beyond any recognizability). Like some screensaver does when it makes the screen look paralyzed. I first swapped the Graphics card, an ELSA Syngery 8, against an ELSA Winner 1000/T2D (that is a S3Trio64DX/V2). WIth that latter card I had terrible trouble with XFree86-4.2.1 under 5.0R. I only got two modes from XFree86 -configure which were 640x480 and 320x240. When I moved the mouse with that graphics card in place it resulted in flickering of the X screen from dark to normal with every other mouse movement. I then removed a 3COM 3C905 to no avail until I found that the DE-203 was the culprit. Question is: Is it the ISA memory of the card (d8000-dffff ?) that caused the trouble or is it something else (I/O, irq)? Anyone seen this before? -- Chris Christoph P. U. Kukulies kukulies@rwth-aachen.de From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 09:57:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0647337B401 for ; Tue, 22 Apr 2003 09:57:09 -0700 (PDT) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 06F7D43FD7 for ; Tue, 22 Apr 2003 09:57:08 -0700 (PDT) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 74753 invoked by uid 1500); 22 Apr 2003 16:57:02 -0000 Date: Tue, 22 Apr 2003 12:57:02 -0400 From: "Kevin A. Pieckiel" To: Terry Lambert Message-ID: <20030422165702.GC31530@pacer.dmz.smartrafficenter.org> References: <20030420210118.GA21255@pacer.dmz.smartrafficenter.org> <3EA32ADA.CC05B003@mindspring.com> <20030421113938.GA31530@pacer.dmz.smartrafficenter.org> <3EA43297.44FC6E44@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <3EA43297.44FC6E44@mindspring.com> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org Subject: Re: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 16:57:09 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 21, 2003 at 11:04:07AM -0700, Terry Lambert wrote: > Things which are allocated by the zone allocator at interrupt > time have a fixed amount of KVA that is set at boot time, before > the VM system is fully up. Even if it were not fully up, the > way it works is by preallocating an address space range to be > later filled in by physical pages (you cannot call malloc() at > interrupt time, but you can take a fault and fill in a backing > page). So the zone size for sockets (inpcb's, tcpcb's) is fixed > at boot time, even though it is derived from the "maxfiles". This--plus the references to zalloci(), zalloc(), and malloc() you gave--are starting to give me an understanding of this. At least, I recognize the differences you're explaining as well as the logic behind those differences. This is really starting to get fascinating. > A problem with the 5.x approach is that this means it's possible > to get NULL returns from allocation routines, when the system is > under memory pressure (because a mapping cannot be established), > when certain of those routines are expected to *never* fail to > obtain KVA space. This is a bit unnerving--or so it would seem, though I'm a bit lost on a couple points here. First, you said: > In 5.x, the zone limits are still fixed to a static boot-time > settable only value -- the same value -- but the actual zone > allocations take place later." =20 Okay, so the basically the kernel is told it has a certain amount of memory guaranteed to be available to it within a certain zone when in fact that memory is not (because it's allocated later, after a time when it may have already been allocated for another purpose). I see how this links to your parenthetical statement: > This > is a serious problem, and has yet to be correctly addressed in > the new allocator code (the problem occurs because the failure to > obtain a mapping occurs before the zone in question hits its > administrative limit). What I fail to see is why this scheme is decidedly "better" than that of the old memory allocator. I understand from the vm source that uma wants to avoid allocating pools of unused memory for the kernel--allocating memory on an as needed basis is a logical thing to do. But losing the guarantee that the allocation routines will not fail and not adjusting the calling functions of those routines seems a bit dumb (since, as you state, the kernel panics). I think this might be a trouble spot for me because of another question.... What is the correct way to address this in the new allocator code? I can come up with an option or two on my own... such as that to which I've already alluded: memory allocation routines that once guaranteed success can no longer be used in such a manner, thus the calling functions must be altered to take this into account. But this is certainly not trivial! And finally: > Basically, everywhere that calls zalloci() > is at risk of panic'ing under heavy load. Am I not getting a point here? I can't find any reference to zalloci() in the kernel source for 5.x (as of a 07 Apr 2003 cvs update on HEAD), and such circumstances don't apply to 4.x (which, of course, is where I DID find them after you mentioned them). > Correct. The file descriptors are dynamically allocated; or rather, > they are allocated incrementally, as needed, and since this is not > at interrupt time, the standard system malloc() can be used. A quick tangent.... when file descriptors are assigned and given to a running program, are they guaranteed to start from zero (or three if you don't close stdin, stdout, and stderr)? Or is this a byproduct of implementation across the realm of Unixes? > An interesting aside here is that the per process open file table, > which holds references to file for the process, is actually > allocated at power-of-2, meaning each time it needs to grow, the > size is doubled, using realloc(), instead of malloc(), to keep the > table allocation contiguous. This means if you use a lot of files, > it takes exponentially increasing time to open new files, since > realloc has to double the size, and then copy everything. For a > few files, this is OK; for 100,000+ files (or network connections) > in a single process, this starts to become a real source of overhead. Now this _IS_ interesting. I would think circumstances requiring 100,000+ files or net connections, though not uncommon, are certainly NOT in the vast majority, but would still have a bone to pick with this implementation. For example, a web server--from which most users expect (demand?) fast response time--that takes time to expand its file table during a connection or request would seem to have unreasonable response times. One would think there is a better way. How much of an issue is this really? (Afterall, I probably wouldn't have inquired about file limits, etc., in the first place if I wasn't intending on implementing something that will require a lot of connections.) Excellent info, Terry. Thanks for sharing it! Kevin pos +=3D screamnext[pos] /* does this goof up anywhere? */ -- Larry Wall in util.c from the perl source code --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+pXRdc3iJbvFgTpIRAt0jAJsF2q1ckS1xK2xbaQ1gSY+1Z2OSXwCcCJzx C5pFEwOsGCep9LJoVXM7Pho= =3vSG -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 10:33:57 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B223837B401 for ; Tue, 22 Apr 2003 10:33:57 -0700 (PDT) Received: from anor.ics.muni.cz (anor.ics.muni.cz [147.251.4.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C56A43F93 for ; Tue, 22 Apr 2003 10:33:56 -0700 (PDT) (envelope-from hopet@ics.muni.cz) Received: from dior.ics.muni.cz (dior.ics.muni.cz [147.251.6.10]) by anor.ics.muni.cz (8.12.1/8.12.1) with ESMTP id h3MHXsNw031360 for ; Tue, 22 Apr 2003 19:33:54 +0200 Received: from kloboucek (root@localhost) (authenticated as hopet with LOGIN) by dior.ics.muni.cz (8.10.1/8.10.0.Beta12) with ESMTP id h3MHXrx00255 for ; Tue, 22 Apr 2003 19:33:54 +0200 (MEST) From: "Petr Holub" To: Date: Tue, 22 Apr 2003 19:35:06 +0200 Message-ID: <004b01c308f5$837ca6a0$2603fb93@kloboucek> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Muni-Virus-Test: Clean Subject: x86-64 support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:33:58 -0000 Hi all, can anybody tell me what's the status of x86-64 (Opteron/Hammer) port? Thanks, Petr ================================================================ Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: Petr.Holub@cesnet.cz phone: +420-541512213 fax: +420-541212747 e-mail: hopet@ics.muni.cz From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 10:44:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC48537B401 for ; Tue, 22 Apr 2003 10:44:42 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-67-115-75-1.dsl.lsan03.pacbell.net [67.115.75.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11A6243F85 for ; Tue, 22 Apr 2003 10:44:42 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id C66BF66D6A; Tue, 22 Apr 2003 10:44:41 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 9E4FA1532; Tue, 22 Apr 2003 10:44:41 -0700 (PDT) Date: Tue, 22 Apr 2003 10:44:41 -0700 From: Kris Kennaway To: omestre@freeshell.org Message-ID: <20030422174441.GA64412@rot13.obsecurity.org> References: <20030422130349.BC1461030E@ws-tor-0004.procergs> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <20030422130349.BC1461030E@ws-tor-0004.procergs> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org Subject: Re: nfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:44:43 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2003 at 10:03:44AM -0300, omestre@freeshell.org wrote: >=20 > Have the FreeBSD 5.0 problems with NFS locking? No. > I have some diskless machines that are not working. (In 4.x work fine). Are you sure you are running the rpc.lockd and rpc.statd services? Kris --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+pX+JWry0BWjoQKURAtbRAJ4wg482MfbR30CZ81/7wNP47izjzwCfTGl8 LQqobzP7uIqaMyftwzrlQhs= =Cgyf -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 10:59:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C3EB37B401 for ; Tue, 22 Apr 2003 10:59:54 -0700 (PDT) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC49543F85 for ; Tue, 22 Apr 2003 10:59:52 -0700 (PDT) (envelope-from vlm@netli.com) Received: (qmail 17089 invoked by uid 84); 22 Apr 2003 17:59:50 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.128998 secs); 22 Apr 2003 17:59:50 -0000 Received: from unknown (HELO netli.com) (172.17.1.38) by mx01-pal-lan.netli.lan with SMTP; 22 Apr 2003 17:59:50 -0000 Message-ID: <3EA582C2.1040102@netli.com> Date: Tue, 22 Apr 2003 10:58:26 -0700 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030125 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: "Kevin A. Pieckiel" References: <20030418214013.GA65290@pacer.dmz.smartrafficenter.org> In-Reply-To: <20030418214013.GA65290@pacer.dmz.smartrafficenter.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: kqueue events X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:59:54 -0000 Kevin A. Pieckiel wrote: > Will the kqueue interface work with pthread ID's, or is it limited > only to system process ID's? If it doesn't work with pthread ID's, > how much trouble is it to modify them and add a pthread ID filter? What are you trying to achieve, by the way? Basically, for the FBSD versions < 5.0 there are two forms of threads available: basic (libc_r) pthreads and linuxthreads from ports. The first type (user-level threads) does the context switching and all the relevant thread management stuff in the user space, so kernel just doesn't have enough information to supply any kind of per-thread-ID notifications with kqueue system call. However, kqueue wrapper in libc_r could be enhanced to support this kind of stuff (it would be a purely user-level library hack). The second type (rfork()-based) is slightly better for you: kqueue should support this natively (system pids are different per each "thread"), and you don't have to modify any default libraries and/or kernel. For 5.0 it seems to be quite a bit more complicated task in every respect. -- Lev Walkin vlm@netli.com From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 11:19:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A32CD37B401 for ; Tue, 22 Apr 2003 11:19:03 -0700 (PDT) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11B8D43FBF for ; Tue, 22 Apr 2003 11:19:02 -0700 (PDT) (envelope-from marcelo-leal@procergs.rs.gov.br) Received: from ws-tor-0004.procergs (unknown [172.28.5.20]) by honolulu.procergs.com.br (Postfix) with ESMTP id 79660A9E9; Tue, 22 Apr 2003 15:18:59 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id A68921030E; Tue, 22 Apr 2003 15:18:55 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id 86B7D1030D; Tue, 22 Apr 2003 15:18:55 -0300 (BRT) From: omestre@freeshell.org To: Kris Kennaway In-Reply-To: Message from Kris Kennaway <20030422174441.GA64412@rot13.obsecurity.org> References: <20030422130349.BC1461030E@ws-tor-0004.procergs> <20030422174441.GA64412@rot13.obsecurity.org> Date: Tue, 22 Apr 2003 15:18:50 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030422181855.A68921030E@ws-tor-0004.procergs> cc: freebsd-hackers@freebsd.org cc: omestre@freeshell.org cc: marcelo-leal@ws-tor-0004.procergs.com.br Subject: Re: nfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 18:19:04 -0000 Yes, the rpcbind, rpc.lockd and rpc.statd are running. I did make a little program to test the lock types, and did let it running two days ago... today i have it almost done :) (50%). I have four tests, and four messages. The two first have been done. Maybe timeout? Thanks From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 11:50:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A809537B401 for ; Tue, 22 Apr 2003 11:50:37 -0700 (PDT) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA0B743FB1 for ; Tue, 22 Apr 2003 11:50:36 -0700 (PDT) (envelope-from marcelo-leal@procergs.rs.gov.br) Received: from ws-tor-0004.procergs (unknown [172.28.5.20]) by honolulu.procergs.com.br (Postfix) with ESMTP id 20FC3AADE for ; Tue, 22 Apr 2003 15:50:35 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id 489111030E; Tue, 22 Apr 2003 15:50:34 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id 32AA41030D for ; Tue, 22 Apr 2003 15:50:34 -0300 (BRT) From: omestre@freeshell.org To: freebsd-hackers@freebsd.org Date: Tue, 22 Apr 2003 15:50:29 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030422185034.489111030E@ws-tor-0004.procergs> Subject: client-side locks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 18:50:38 -0000 Hello again, I have saw the "FreeBSD 5.0 - Release notes", and there have notes about client-side locks in FreeBSD 5.0. And i'm having problems with locks in Free 5.0... Can i disable that? Because the 4.x are working fine! The locks in 5.0 are working, but after two, or three days timeout (i guess that is timeout, the programs do not show me nothing) simply after a long time, it works. thanks. ps.: The machines are diskless. --- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 12:55:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E1CD37B401 for ; Tue, 22 Apr 2003 12:55:44 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-67-115-75-1.dsl.lsan03.pacbell.net [67.115.75.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E036043FD7 for ; Tue, 22 Apr 2003 12:55:43 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id AAA0A66D6A; Tue, 22 Apr 2003 12:55:43 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 897DE1536; Tue, 22 Apr 2003 12:55:43 -0700 (PDT) Date: Tue, 22 Apr 2003 12:55:43 -0700 From: Kris Kennaway To: omestre@freeshell.org Message-ID: <20030422195543.GA65221@rot13.obsecurity.org> References: <20030422130349.BC1461030E@ws-tor-0004.procergs> <20030422174441.GA64412@rot13.obsecurity.org> <20030422181855.A68921030E@ws-tor-0004.procergs> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20030422181855.A68921030E@ws-tor-0004.procergs> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org cc: marcelo-leal@ws-tor-0004.procergs.com.br cc: Kris Kennaway Subject: Re: nfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 19:55:44 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2003 at 03:18:50PM -0300, omestre@freeshell.org wrote: >=20 > Yes, the rpcbind, rpc.lockd and rpc.statd are running. And on the server? Kris --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+pZ4/Wry0BWjoQKURAtmaAJsEV5ODP/zxMk+rlBv3HmMgStHMnQCfVCUh y7QJeMkRqBDM+HL6qbg9B68= =eNZx -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 13:11:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FC2F37B401 for ; Tue, 22 Apr 2003 13:11:47 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9173743FAF for ; Tue, 22 Apr 2003 13:11:46 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0258.cvx40-bradley.dialup.earthlink.net ([216.244.43.3] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 198474-0006dN-00; Tue, 22 Apr 2003 13:11:36 -0700 Message-ID: <3EA5A18F.5150DB2@mindspring.com> Date: Tue, 22 Apr 2003 13:09:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin A. Pieckiel" References: <20030420210118.GA21255@pacer.dmz.smartrafficenter.org> <3EA32ADA.CC05B003@mindspring.com> <20030421113938.GA31530@pacer.dmz.smartrafficenter.org> <3EA43297.44FC6E44@mindspring.com> <20030422165702.GC31530@pacer.dmz.smartrafficenter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a49a9ed930335bb0e94079a0f619d228be387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: maxfiles, file table, descriptors, etc... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 20:11:47 -0000 "Kevin A. Pieckiel" wrote: [ ... FreeBSD lazy allocation of KVA space for zalloci() use ... ] > What I fail to see is why this scheme is decidedly "better" than > that of the old memory allocator. I understand from the vm source > that uma wants to avoid allocating pools of unused memory for the > kernel--allocating memory on an as needed basis is a logical thing > to do. But losing the guarantee that the allocation routines will > not fail and not adjusting the calling functions of those routines > seems a bit dumb (since, as you state, the kernel panics). I think > this might be a trouble spot for me because of another question.... Eventually, the calling functions will be adjusted, I think. The reason the new code (Jeff's code) is better is that it doesn't task-commit a limited resource. When you compile a kernel with a specific MAXFILES (or set "kern.maxfiles" in the loader) in 4.x, you eat an unrecoverable chunk of the KVA, which is a scarce resource. This is a problem, if you are a general purpose system, since at any point you can't know what resource is going to be in the highest demand, at any given point in time. Even the 5.x has a fault here, in that, once allocated, the memory is type-stable; luckily, however, most systems maintain homogeneous loads over time, so you aren't going to see radical swings between being a scientific computation platform vs. a web server, vs. a shell machine, etc., without reboots in between, as the machine finds itself repurposed. For a platform allocated a specific task, it's also helpful to have the new code. In general, what happens in a platform that has a specific role that is never going to change is that it is manually tuned to that role. This tuning process is complex and time consuming, and requires both a lot of knowledge of the OS, and a lot of domain specific knowledge. Even then, people tend to make mistakes. By allowing the limits to be raised to the point that they are irrelevent, and then modifying the code to allocate resources, as necessary, it provides for a much simpler tuning experience to get from 30% of performance to 90% of performance, without a lot of work (the last 10% is still really hard, and requires domain specific knowledge). > What is the correct way to address this in the new allocator code? There are several ways of doing this. It's probably a good idea to make the kernel code in question insensitive to NULL returns, as a general rule. This helps the code be more resilient to future changes, and it allows immediate relief from high load situations: instead of hanging until a request can be satisfied, the request is failed, and the pressure on the system is reduced. It's the same theory you get from seeing a lot of cars jammed up in front of you, and turning right, instead of heading into the jam with everyone else, and making things worse. It's also probably a good idea to use this as an indicator of where code needs to be refactored. Most of the problems in 5.x are a result of legacy code that should be refactored, that's being locked down, instead. What happens in this case is that locks get held over function call boundaries, but they do not have to come back up over those boundaries in order to be released; e.g. A() locks X, A() calls B(), B() calls C(), C() unlocks X. Every time you see a "lock order reversal" or "LOR" posting to the list, it's either because someone has been confused about "locking code" vs. "locking data", or it's because there's a layering abstraction violation that makes some lock acquisition and relese non-reflexive, like this. Probably the easiest way of dealing with this problem is to establish page mappings for all of physical memory, up front, and all of KVA, and then modify the mappings and/or "give them away", instead of trying to allocate new ones when you're in a memory pressure situation. One obvious fix for the zalloci() code would be to modify the order in which page mappings are obtained, when new pages are rquired by a given zone, and then add a second administrative limit to the zone structure. Initially set the administrative limit equal to the hard limit on the zone, when the zone is created, and then if you fail to obtain the page mapping, lower the administrative limit to the current limit. The effect of this would be to cause the zalloci() to fail in a way that it's expected to fail: virtually, "because we have hit our administratively agreed limit", rather than "because we ran out of page mappings". > I can come up with an option or two on my own... such as that to > which I've already alluded: memory allocation routines that once > guaranteed success can no longer be used in such a manner, thus the > calling functions must be altered to take this into account. But > this is certainly not trivial! Yes. This is non-trivial, and it should be done anyway. 8-). See above. > > Basically, everywhere that calls zalloci() > > is at risk of panic'ing under heavy load. > > Am I not getting a point here? I can't find any reference to > zalloci() in the kernel source for 5.x (as of a 07 Apr 2003 cvs > update on HEAD), and such circumstances don't apply to 4.x (which, > of course, is where I DID find them after you mentioned them). The calls have been changed; I should say "everywhere zalloci() has been replaced with something which has a NULL-return semantic". > > Correct. The file descriptors are dynamically allocated; or rather, > > they are allocated incrementally, as needed, and since this is not > > at interrupt time, the standard system malloc() can be used. > > A quick tangent.... when file descriptors are assigned and given to > a running program, are they guaranteed to start from zero (or three > if you don't close stdin, stdout, and stderr)? Or is this a byproduct > of implementation across the realm of Unixes? The descriptor number is an index into the per process open file table. This table *always* starts at 0, but may start with some slots filled in already (usually stdin/stdout/stderr, but really, anything it's parent process didn't have marked "close on exec", and which doesn't force those semantics by failing dup2(), is copied). The place to look for this is: struct proc *p; /* sys/proc.h */ struct filedesc *fdescp; /* sys/filedesc.h */ struct file *fp0; /* sys/file.h */ fdescp = p->p_fd; fp0 = fdescp->fd_ofiles[ 0 /* this is my fd */ ]; The place you see these indices translated are in falloc(), fget(), etc., descriptor manipulation, which is located in the kernel source file /usr/src/sys/kern/kern_descrip.c. For an interesting case study, consider an already open file on which you want to call "fstat" from user space. Then look in /usr/src/sys/kern/kern_descrip.c for the definition of the function "fstat", which implements this system call (the struct "fstat_args" is defined in a block comment above the function, for convenience of the reader). It's not commented in detail, but what happens is: o You take a trap for the system call via INT 0x80 o The system call arguments are converted to a linear set, which is cast to a "struct fstat_args *" by the function entry (from a "void *"). o A lock is held to prevent reentrancy o fget() translates the index (descriptor) into a "struct file *"; as a side effect, this obtains a reference, so that if someone else tries to close the file out from under you, you hold it open. o The fo_ ("file operation") stat is called, which copies the stat information into the stack region "ub", which is a "struct stat". o The data in "ub" is copied out into the user process address space, into the buffer whose address argument was supplied to the system call. o fdrop() is called to release the reference; if this was the last reference (unlikely, given the specific lock being held here), then the fdp is released back to the system, and the file is truly closed. o The lock is released. o Any error which occurred is returned in %AX, which gets given back to the system as a -1 return, with errno set to the error. So, although it's abstracted by fget/fdrop, it's really accessing an allocated linear array of "struct file", for which the user space file descriptor is an index into that array. [ ... per process open file table allocation inefficiencies ... ] > Now this _IS_ interesting. I would think circumstances requiring > 100,000+ files or net connections, though not uncommon, are certainly > NOT in the vast majority, but would still have a bone to pick with this > implementation. For example, a web server--from which most users > expect (demand?) fast response time--that takes time to expand its > file table during a connection or request would seem to have > unreasonable response times. Yes. It's one of the things you rewrite when you are trying to get uniform and high performance out of a system. 100,000 net connections is uncommon; until two years ago, no one has really stressed FreeBSD above 32,768 connections, after which a credentials bug would cause a kernel panic when enough sockets had been closed. Even at smaller numbers of open files, though, the allocation causes "lurches" in server behaviour; you can see the dips as inverse spikes from the allocations on "webbench", for example, even for 10,000 and 20,000 connections. > One would think there is a better way. It's all about tradeoffs. One way is to force the table size large, to start with, using dup2(). > How much of an issue is this really? You mean compared to having to disable PSE and PG_G, or some other perforrmance issues? Not much of one. But every little bit hurts. > Excellent info, Terry. Thanks for sharing it! It's not all that great; I'm sure I'll be corrected on some things with regard to 5.x, since it's a moving target, and it's not really possible to state anything authoritatively about it, since it will be changed out from under you to address any easy complaints, so by the time someone goes and looks at it, what you've said is not true any more. 8-) 8-). Basically, I answered because you asked. I do that a lot, even in private email; this got to the list because you Cc:'ed the list, not because I would have put it there if you'd asked in private email. Lots of things never see the list; some people ask things in private because of competitive advantage, or because I've stated a non-disclosure requirement on a small set of topics. 8-). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 05:53:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34E0537B401 for ; Wed, 23 Apr 2003 05:53:22 -0700 (PDT) Received: from marvin.muc.de (marvin.muc.de [193.149.48.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 8BDF043FA3 for ; Wed, 23 Apr 2003 05:53:20 -0700 (PDT) moderators-muc-lists-freebsd-hackers-owner@moderators.muc.de) Received: (qmail 32772 invoked by alias); 23 Apr 2003 12:51:10 -0000 Delivered-To: moderators-muc-lists-freebsd-hackers@moderators.muc.de Received: (qmail 32767 invoked from network); 23 Apr 2003 12:51:10 -0000 Received: from mail.fu-berlin.de (root@160.45.11.165) by marvin.muc.de with SMTP; 23 Apr 2003 12:51:10 -0000 Received: by mail.fu-berlin.de (Smail3.2.0.98) from Curry.ZEDAT.FU-Berlin.DE (160.45.10.36) with esmtp id ; Wed, 23 Apr 2003 14:53:18 +0200 (MEST) Received: by Curry.ZEDAT.FU-Berlin.DE (Smail3.2.0.98) from news.fu-berlin.de with bsmtp id ; Wed, 23 Apr 2003 14:53:18 +0200 (MEST) To: muc-lists-freebsd-hackers@moderators.muc.de Path: port-212-202-187-237.reverse.qdsl-home.DE!not-for-mail From: benny Newsgroups: mpc.lists.freebsd.hackers,muc.lists.freebsd.hackers Date: Wed, 23 Apr 2003 14:57:34 +0200 Lines: 41 Message-ID: <20030423145734.3ea7abfb.linux@marcrenearns.de> References: <2451304609.20030319010338@serebryakov.spb.ru> X-Orig-NNTP-Posting-Host: port-212-202-187-237.reverse.qdsl-home.de (212.202.187.237) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orig-X-Trace: fu-berlin.de 1051102397 7113403 212.202.187.237 (16 [147067]) X-Newsreader: Sylpheed version 0.8.2claws (GTK+ 1.2.10; i386-portbld-freebsd4.7) X-Mailman-Approved-At: Wed, 23 Apr 2003 06:10:26 -0700 Subject: Re: Sound drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 12:53:22 -0000 what a great idea! the oss-driver is so performance-consuming - it sucks. there are some great other envy24-chip-soundcards, like terratec ews 88mt or the famous hammerfall. If you would add an alsa/jack compatibility-layer (for use with ardour), I even would donate to you!! its time to get freebsd usable for realtime-applications, as audio and video-production-evironment!!! please keep me informed perhaps some links for you: http://vcc.urz.tu-dresden.de/~fleck/bookmarks/freebsd_audiovideo.html http://info.iet.unipi.it/~luigi/sound.html (outdated) http://www.linuxdj.com/mucos/intro.html http://people.FreeBSD.org/~faulkner/multimedia/mm.html (outdated) http://myweb.cableone.net/eviltwin69/Arcana.html (Linux) http://www.cs.duke.edu/~anderson/freebsd/maestro3xxx/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/oss.html benny Am Wed, 19 Mar 2003 01:03:38 +0300 schrieb Lev Serebryakov : > Hello, hackers! How are you? > > I want to write sound driver for FreeBSD (pcm bridge driver) for > Envy24 chip and M-Audio Audiophile 2496 sound card. > > Is here any documentation about pcm architecture? I've looked > through sources, but I have still some questions... > > Lev Serebryakov > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 08:20:17 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C4D037B401 for ; Wed, 23 Apr 2003 08:20:17 -0700 (PDT) Received: from hotmail.com (f104.law11.hotmail.com [64.4.17.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCB1143FBD for ; Wed, 23 Apr 2003 08:20:16 -0700 (PDT) (envelope-from freebsd_questions@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 23 Apr 2003 08:20:16 -0700 Received: from 164.164.86.66 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 23 Apr 2003 15:20:16 GMT X-Originating-IP: [164.164.86.66] X-Originating-Email: [freebsd_questions@hotmail.com] From: "Abhay Srivastava" To: freebsd-hackers@freebsd.org Date: Wed, 23 Apr 2003 20:50:16 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Apr 2003 15:20:16.0688 (UTC) FILETIME=[D8253300:01C309AB] Subject: Porting from 3.1 to 4.7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 15:20:17 -0000 Hi, I am porting a code from FreeBSD 3.1 to FreeBSD 4.7. However, the code for executing Cam commands fail. The error is : (pass0:sym0:0:0:0): MODE SELECT(06). CDB: 15 1 0 0 10 0 (pass0:sym0:0:0:0): ILLEGAL REQUEST asc:26,0 (pass0:sym0:0:0:0): Invalid field in parameter list field replaceable unit: 7 sks:8f,8 Is there any change in the way cam commands are given in 4.7 as this code runs perfectly on 3.1. Kindly cc to my Id also as I am not a member on this mailing list. Regards, Jonathan. _________________________________________________________________ Celebrate Easter. Eggs, bunnies et al. http://server1.msn.co.in/sp03/easter/index.asp Send e-cards. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 08:28:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ADD137B401 for ; Wed, 23 Apr 2003 08:28:32 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53FAD43F3F for ; Wed, 23 Apr 2003 08:28:31 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.9/8.12.5) with ESMTP id h3NFSTPM058240; Wed, 23 Apr 2003 09:28:29 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.9/8.12.5/Submit) id h3NFSTKY058239; Wed, 23 Apr 2003 09:28:29 -0600 (MDT) (envelope-from ken) Date: Wed, 23 Apr 2003 09:28:29 -0600 From: "Kenneth D. Merry" To: Abhay Srivastava Message-ID: <20030423092829.A58203@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from freebsd_questions@hotmail.com on Wed, Apr 23, 2003 at 08:50:16PM +0530 cc: freebsd-hackers@freebsd.org Subject: Re: Porting from 3.1 to 4.7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 15:28:32 -0000 On Wed, Apr 23, 2003 at 20:50:16 +0530, Abhay Srivastava wrote: > > Hi, > I am porting a code from FreeBSD 3.1 to FreeBSD 4.7. However, the code for > executing Cam commands fail. The error is : > > (pass0:sym0:0:0:0): MODE SELECT(06). CDB: 15 1 0 0 10 0 > > (pass0:sym0:0:0:0): ILLEGAL REQUEST asc:26,0 > > (pass0:sym0:0:0:0): Invalid field in parameter list field replaceable unit: > 7 sks:8f,8 > > Is there any change in the way cam commands are given in 4.7 as this code > runs perfectly on 3.1. > > Kindly cc to my Id also as I am not a member on this mailing list. Look at the sense key specific information. It's complaining about byte 8, bit 7 in the parameter list. So look at what you're sending. If you think this is a FreeBSD problem, it's a little hard to say what it might be without looking at the code. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 08:42:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C00937B401 for ; Wed, 23 Apr 2003 08:42:42 -0700 (PDT) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4B1743F93 for ; Wed, 23 Apr 2003 08:42:41 -0700 (PDT) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id IAA31780 for ; Wed, 23 Apr 2003 08:42:40 -0700 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: freebsd-hackers@freebsd.org Date: Wed, 23 Apr 2003 08:43:22 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <3EA6522A.25198.6D6A8B3D@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Subject: dump routine for mlx devices X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 15:42:42 -0000 Hello, I need to get a crash dump and the only disk controller on the system in question is an eXtremeRAID1100 (DAC1164P) handled through the mlx driver. I'm running FreeBSD 4.7-release + security fixes. dumping to dev #mlxd/0x20001, offset 9372672 dump failed, reason: device doesn't support a dump routine Before I go try to write my own dump routine: Has anyone else already invented that wheel or is the wheel too difficult a pursuit in this case due to peculiarities of this hardware? I've only had a quick glance at the source under /usr/src/sys/dev/ and at first glance the only devices that appear to support crash dumps are aac_disk, ata_disk, ida_disk, and ccd. That last one (ccd) could be a point of interest. Is it possible to create a ccd device from a spare mlxd device? If so, is it also feasible to swap and dump to that ccd device or would it fail because the "real" device didn't support dumps? Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 09:56:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C4DE37B408 for ; Wed, 23 Apr 2003 09:56:10 -0700 (PDT) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8591843F85 for ; Wed, 23 Apr 2003 09:56:09 -0700 (PDT) (envelope-from chris@unixpages.org) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id EA0E0A91E; Wed, 23 Apr 2003 18:56:08 +0200 (CEST) Received: by gondor.middleearth (Postfix, from userid 1001) id 58D6946A4; Wed, 23 Apr 2003 18:56:07 +0200 (CEST) Date: Wed, 23 Apr 2003 18:56:06 +0200 From: Christian Brueffer To: Lev Serebryakov Message-ID: <20030423165606.GD26749@unixpages.org> References: <2451304609.20030319010338@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8nsIa27JVQLqB7/C" Content-Disposition: inline In-Reply-To: <2451304609.20030319010338@serebryakov.spb.ru> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D cc: hackers@FreeBSD.ORG Subject: Re: Sound drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 16:56:13 -0000 --8nsIa27JVQLqB7/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2003 at 01:03:38AM +0300, Lev Serebryakov wrote: > Hello, hackers! How are you? >=20 > I want to write sound driver for FreeBSD (pcm bridge driver) for > Envy24 chip and M-Audio Audiophile 2496 sound card. >=20 > Is here any documentation about pcm architecture? I've looked > through sources, but I have still some questions... >=20 > Lev Serebryakov >=20 >=20 You might want to check the sound section of the developers handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/oss.ht= ml Also of interest might be this: http://people.freebsd.org/~orion/files/sound.txt Especially the 'Contributing' section at the bottom. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --8nsIa27JVQLqB7/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+psWmbHYXjKDtmC0RAqSxAJoD4Fl8magb/zhH0irHiXIuT/w+DACgnq0H cJ6n/BwsjWbiVVMK3PWm+Qo= =NSsQ -----END PGP SIGNATURE----- --8nsIa27JVQLqB7/C-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 10:11:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68D4C37B401 for ; Wed, 23 Apr 2003 10:11:32 -0700 (PDT) Received: from relay3.softcomca.com (relay3.softcomca.com [168.144.1.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B558543F3F for ; Wed, 23 Apr 2003 10:11:31 -0700 (PDT) (envelope-from akanwar@digitarchy.com) Received: from M2W083.mail2web.com ([168.144.251.194]) by relay3.softcomca.com with Microsoft SMTPSVC(5.0.2195.5576); Wed, 23 Apr 2003 13:11:33 -0400 Message-ID: <269620-220034323171027159@M2W083.mail2web.com> X-Priority: 3 X-Originating-IP: 66.162.33.181 X-URL: http://mail2web.com/ From: "akanwar@digitarchy.com" To: freebsd-hackers@freebsd.org Date: Wed, 23 Apr 2003 13:10:27 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 23 Apr 2003 17:11:33.0326 (UTC) FILETIME=[63BB4EE0:01C309BB] Subject: fxp0: device timeout X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: akanwar@digitarchy.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 17:11:32 -0000 Hi, I am trying to pxeboot a rackable 1u box with freebsd 4=2E8-RELEASE and 4=2E6=2E2-RELEASE=2E The fxp interface gets stuck at the following errors: fxp0: device timeout fxp0: device timeout repeated ad infinitum=2E fxp0: port 0xc400-0xc43f mem 0xfe4a0000-0xfe4bffff,0xfe4fe000-0xfe4fefff irq 5 at device 1=3D2E0 on pci= 1 fxp0: Ethernet address 00:e0:81:25:44:27 This is a Tyan 2721 board with dual Xeon 2=2E4GHz I have tried creating kernels with SMP and APIC_IO turned off but still the same result=2E I then gave up on pxe and installed via CD-ROM=2E but the fxp interface refuses to come up and keeps flashine the same error on the console=2E Has this been seen before? Any suggestions ? Thanks, -ansh -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 16:15:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 367DD37B401 for ; Wed, 23 Apr 2003 16:15:23 -0700 (PDT) Received: from priv-edtnes44.telusplanet.net (outbound05.telus.net [199.185.220.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 699CD43FBD for ; Wed, 23 Apr 2003 16:15:22 -0700 (PDT) (envelope-from pfak@telus.net) Received: from oxygen ([154.5.44.11]) by priv-edtnes44.telusplanet.net (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030423231522.XBZS3906.priv-edtnes44.telusplanet.net@oxygen> for ; Wed, 23 Apr 2003 17:15:22 -0600 Message-ID: <001901c309ee$36029070$c601a8c0@oxygen> From: "Peter" To: Date: Wed, 23 Apr 2003 16:15:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Keeping a large shellbox stable and secure X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 23:15:23 -0000 Hello, I'm going to be starting to run a large shell box again, about 900 users (basically free shell accounts, crazy isn't it?). I would like to avoid the same mistakes I made before, my system was pretty secure (I'm running FreeBSD, and I keep everything up to date and tuned). I had a problem with the boxes crashing a lot, and in this case the box will no longer be hosted at my house, but by an ISP, they are also sponsoring it so it won't be "supported", which means that I will have to buy a reboot switch (one time fee of $50), but I would like to avoid having to hard reset the box all the time. Are there any methods that have been proven to work in keeping your system stable, so that is harder to crash. I found that even when I was using login.conf, the system would crash a lot from people running programs that would use excessive system resources to attempt to crash the system and so forth. Are there any proven methods that you have used? System tweaks, etc. That seem to work under high system loads? Such as sysctl.conf, rc.conf, etc. What programs would you recommend to install on the system, kernel patches, etc? That have helped you maintain a highly loaded, and a box that will come under scrutiny from people try to attack, crack it, crack from it, flood from it, etc. Would ipfw2 or Ipfilter be better? Should I run RELENG_4 or RELENG_4_8. Any ideas would be appreciated. Basically, I'm attempting to make this box as stable and secure as possible. Anything would be appreciated. Thanks, (Sorry if I posted this to the wrong list) -- Peter Kieser From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 19:54:42 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BEBE37B401 for ; Wed, 23 Apr 2003 19:54:42 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1FEA43FA3 for ; Wed, 23 Apr 2003 19:54:39 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 220EF5308; Thu, 24 Apr 2003 04:54:36 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Nickolay A. Kritsky" From: Dag-Erling Smorgrav Date: Thu, 24 Apr 2003 04:54:36 +0200 In-Reply-To: <10695996045.20030416191035@star.spb.ru> ("Nickolay A. Kritsky"'s message of "Wed, 16 Apr 2003 19:10:35 +0400") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 References: <1222010669.20030415223730@star.spb.ru> <20030416073329.GB298@exmatis1.cnrm.meteo.fr> <2377892423.20030416140852@star.spb.ru> <20030416121406.GA229@exmatis1.cnrm.meteo.fr> <10695996045.20030416191035@star.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Igor Pokrovsky cc: freebsd-hackers@freebsd.org Subject: Re: Kernel variables - where is TFM? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 02:54:42 -0000 "Nickolay A. Kritsky" writes: > Looks like the only interface to look up sysctl description is grep(1) > :-\ des@dwp ~% sysctl -d kern.clockrate kern.clockrate: Rate and period of various kernel clocks DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 20:02:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEF3437B401; Wed, 23 Apr 2003 20:02:20 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 204EF43FBD; Wed, 23 Apr 2003 20:02:20 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 342475308; Thu, 24 Apr 2003 05:02:17 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Alex Semenyaka From: Dag-Erling Smorgrav Date: Thu, 24 Apr 2003 05:02:17 +0200 In-Reply-To: <20030420004639.GA52081@snark.ratmir.ru> (Alex Semenyaka's message of "Sun, 20 Apr 2003 04:46:39 +0400") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 References: <20030420004639.GA52081@snark.ratmir.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: freebsd-current@freebsd.org cc: freebsd-standards@freebsd.org Subject: Re: tjr@@freebsd.org, imp@freebsd.org, ru@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 03:02:21 -0000 Alex Semenyaka writes: > Brief description what was done: I've chanched the arithmitics in the /bin/sh > from 32 bits to 64 bits. There are some doubts that it conforms to the > standards: it does, I have send a quotations to -standards, there were no > objections. Couple of people advuces me to use intmax_t and %jd - I've rewritten > the patch, now there is those species instead of long long and %qd. The last > question was performance, I will show the results of measurements below. Performance is irrelevant. Anyone who is doing so much arithmetic in the shell that performance is an issue should take a long hard look at dc(1). The only issues here are 1) correctness 2) portability (long long / %qd is not portable) and 3) standards compliance. You can safely ignore anyone trying to tell you otherwise. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 20:03:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B971A37B401 for ; Wed, 23 Apr 2003 20:03:53 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 232E543F75 for ; Wed, 23 Apr 2003 20:03:53 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 0F4A65308; Thu, 24 Apr 2003 05:03:46 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Petr Holub" From: Dag-Erling Smorgrav Date: Thu, 24 Apr 2003 05:03:45 +0200 In-Reply-To: <004b01c308f5$837ca6a0$2603fb93@kloboucek> ("Petr Holub"'s message of "Tue, 22 Apr 2003 19:35:06 +0200") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 References: <004b01c308f5$837ca6a0$2603fb93@kloboucek> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org Subject: Re: x86-64 support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 03:03:54 -0000 "Petr Holub" writes: > can anybody tell me what's the status of x86-64 (Opteron/Hammer) port? http://www.freebsd.org/~peter/hammer.txt DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 21:05:13 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7546837B401 for ; Wed, 23 Apr 2003 21:05:13 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B414F43F85 for ; Wed, 23 Apr 2003 21:05:12 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 954D72A8A9; Wed, 23 Apr 2003 21:05:12 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav In-Reply-To: Date: Wed, 23 Apr 2003 21:05:12 -0700 From: Peter Wemm Message-Id: <20030424040512.954D72A8A9@canning.wemm.org> cc: Petr Holub cc: freebsd-hackers@FreeBSD.org Subject: Re: x86-64 support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 04:05:13 -0000 Dag-Erling Smorgrav wrote: > "Petr Holub" writes: > > can anybody tell me what's the status of x86-64 (Opteron/Hammer) port? > > http://www.freebsd.org/~peter/hammer.txt I updated that today.. Its reaching single user from disk and netboot. >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader64 boot: 0:ad(0,g)/boot/loader Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (peter@daintree.yahoo.com, Tue Apr 8 21:33:49 PDT 2003) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x1a14a0 data=0x56e78+0x44bd8 syms=[0x8+0x39948+0x8+0x2f2f0] Type '?' for a list of commands, 'help' for more detailed help. OK boot -s Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #514: Wed Apr 23 17:28:31 PDT 2003 peter@daintree.yahoo.com:/home/peter/fbp4/hammer/sys/x86_64/compile/GENERIC Preloaded elf64 kernel "/boot/kernel/kernel" at 0x404a7000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 3141592 Hz CPU: AMD ClawHammer(tm) (3.14-MHz Hammer-class CPU) Origin = "AuthenticAMD" Id = 0xf00 Stepping = 0 Features=0x78bfbff AMD Features=0xe0500000<,AMIE,,DSP,3DNow!> real memory = 536805376 (511 MB) avail memory = 504209408 (480 MB) npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 6.0 on pci0 pci2: on pcib2 ohci0: mem 0xe9521000-0xe9521fff irq 11 at device 0.0 on pci2 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe9523000-0xe9523fff irq 11 at device 1.0 on pci2 usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pci2: at device 4.0 (no driver attached) bge0: mem 0xe9500000-0xe950ffff irq 10 at device 5.0 on pci2 bge0: Ethernet address: 00:04:76:eb:a9:cd miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto fxp0: port 0xc000-0xc03f mem 0xe9400000-0xe94fffff,0xe9522000-0xe9522fff irq 11 at device 7.0 on pci2 fxp0: Ethernet address 00:d0:b7:23:af:0d miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pci0: at device 7.5 (no driver attached) orm0: