dummynet.expire q'n

[rihad]

Hi,

From FreeBSD 7.0's ipfw manual:

net.inet.ip.dummynet.expire: 1
  Lazily delete dynamic pipes/queue once they have no pending traf-
  fic.  You can disable this by setting the variable to 0, in which
  case the pipes/queues will only be deleted when the threshold is
  reached.

Can a kernel guru enlighten me if there's any risk of a pipe going away 
from under your feet when an existing firewall rule is using it, 
resulting in a dead link where no traffic can be passed? As I don't 
really know how "lazy deletion" works, It's very important this never 
happens, so I've set this to 0 just to be safe, but the pipe count is 
growing!


# ipfw pipe show | wc -l
 229
with only 60 or so active ipfw pipe rules that triggered pipe creation.

It seems that deleting an ipfw pipe rule will not delete the pipe behind 
it when net.inet.ip.dummynet.expire is 0? OTOH, won't setting it to 1 
make pipes suddenly disappear by whatever "lazy deletion" means?


Thanks.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: i386/120264: double fault in freebsd 7.0

[kris]

Synopsis: double fault in freebsd 7.0

State-Changed-From-To: open->closed
State-Changed-By: kris
State-Changed-When: Tue Feb 5 11:02:08 UTC 2008
State-Changed-Why: 
Submitter rejects inbound email

http://www.freebsd.org/cgi/query-pr.cgi?pr=120264
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: i386/120264: double fault in freebsd 7.0

[Kris Kennaway]

The following reply was made to PR i386/120264; it has been noted by GNATS.

From: Kris Kennaway <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:  
Subject: Re: i386/120264: double fault in freebsd 7.0
Date: Tue, 05 Feb 2008 11:58:26 +0100

 Submitter forgot to give us any useful details about their system 
 configuration, but using my magical telepathy hat I sense that they are 
 using the nve driver, which is known to be broken.  A quick tarot card 
 reading predicts that the nfe driver will avoid the panic.
 
 Kris
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

named.root

[Petri Helenius]

Any chance the recent root zone changes would make it to 7.0?

Pete

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/120304: [netgraph] [patch] netgraph source assumes 32-bit timeval on AMD64

[linimon]

Synopsis: [netgraph] [patch] netgraph source assumes 32-bit timeval on AMD64

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Feb 5 22:29:47 UTC 2008
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=120304
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

1 Gb network NFS issues

[Nicholas Kulikov]

Hello all,

I'm trying setup NFS in 1 Gb home network and found some strange issues:

Current NFS performance is about 30-35 Mb/s but few days ago i had  
40-45 Mb/s. I've made some changes in server configuration (moved to  
FreeBSD 6.3 and changed network driver to nfe) and I can't catch what  
is wrong...


Network structure:


NFS server (FreeBSD 6.3)
   |
   | 1 Gb link
   |
NFS client (Mac OS X 10.5.1)

Server configuration
-
nfe0: flags=8843 mtu 8000
options=48

Client configuration

en0: flags=8863 mtu 8000
media: autoselect (100baseTX ) status: active

client mount share by using the following parameters: tcp vers=3  
rsize=40960 wsize=40960 readahead=16 rdirplus nolocks intr noatime



I've tried copy big file (about 3 Gb) and tcdump-ed client and server  
packets:


07:11:08.350744 IP (tos 0x0, ttl 64, id 51461, offset 0, flags [DF],  
proto TCP (6), length 176) 192.168.254.249.nfs >  
192.168.254.254.2468561782: reply ok 124 access attr: REG 660 ids  
1001/1006 sz 3958224896 nlink 1 rdev 133/134414584 fsid 5e fileid  
2013005 a/m/ctime 1199479211.00 1199479280.00  
1201346449.00 c 001f
07:11:08.350793 IP (tos 0x0, ttl 64, id 46719, offset 0, flags [DF],  
proto TCP (6), length 52) 192.168.254.254.49158 >  
192.168.254.249.nfsd: ., cksum 0x7f70 (incorrect (-> 0xd9e5),  
22844:22844(0) ack 27581 win 65535 
07:11:08.350988 IP (tos 0x0, ttl 64, id 9526, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561783 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 0
07:11:08.351069 IP (tos 0x0, ttl 64, id 8470, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561784 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
32768
07:11:08.351145 IP (tos 0x0, ttl 64, id 65343, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561785 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
65536
07:11:08.351242 IP (tos 0x0, ttl 64, id 11022, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561786 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
98304
07:11:08.351314 IP (tos 0x0, ttl 64, id 59209, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561787 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
131072
07:11:08.351383 IP (tos 0x0, ttl 64, id 39733, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561788 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
163840
07:11:08.351450 IP (tos 0x0, ttl 64, id 33325, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561789 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
196608
07:11:08.351516 IP (tos 0x0, ttl 64, id 50481, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561790 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
229376
07:11:08.351582 IP (tos 0x0, ttl 64, id 50464, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561791 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
262144
07:11:08.351658 IP (tos 0x0, ttl 64, id 37215, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561792 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
294912
07:11:08.351739 IP (tos 0x0, ttl 64, id 6496, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561793 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
327680
07:11:08.351750 IP (tos 0x0, ttl 64, id 49495, offset 0, flags [DF],  
proto TCP (6), length 52) 192.168.254.249.nfsd >  
192.168.254.254.49158: ., cksum 0x15e5 (correct), 27581:27581(0) ack  
23076 win 49943 
07:11:08.351754 IP (tos 0x0, ttl 64, id 36632, offset 0, flags [DF],  
proto TCP (6), length 52) 192.168.254.249.nfsd >  
192.168.254.254.49158: ., cksum 0x1501 (correct), 27581:27581(0) ack  
23308 win 49939 
07:11:08.351758 IP (tos 0x0, ttl 64, id 21313, offset 0, flags [DF],  
proto TCP (6), length 52) 192.168.254.249.nfsd >  
192.168.254.254.49158: ., cksum 0x141c (correct), 27581:27581(0) ack  
23540 win 49936 
07:11:08.351783 IP (tos 0x0, ttl 64, id 50759, offset 0, flags [DF],  
proto TCP (6), length 52) 192.168.254.249.nfsd >  
192.168.254.254.49158: ., cksum 0x1338 (correct), 27581:27581(0) ack  
23772 win 49932 
07:11:08.351801 IP (tos 0x0, ttl 64, id 56942, offset 0, flags [DF],  
proto TCP (6), length 52) 192.168.254.249.nfsd >  
192.168.254.254.49158: ., cksum 0x1254 (correct), 27581:27581(0) ack  
24004 win 49928 
07:11:08.351818 IP (tos 0x0, ttl 64, id 13319, offset 0, flags [DF],  
proto TCP (6), length 168) 192.168.254.254.2468561794 >  
192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @  
360448
07:11:08.351904 IP (tos 0x0, ttl 64, id 17022,