Re: bad NFS/UDP performance
it more difficult than I expected. for one, the kernel date was missleading, the actual source update is the key, so the window of changes is now 28/July to 19/August. I have the diffs, but nothing yet seems relevant. on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' give the same throughput, which seem to point to UDP changes ... Can you post the network-numbers? so I ran some more test, these are for writes IO: server is a NetApp: kernel from 18/08/08 00:00:0 : /- UDP // TCP ---/ 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s 64*512602 0.20s 79.98MB 0.20s 78.44MB/s 128*512301 0.18s 86.51MB 0.22s 71.53MB/s 256*512150 0.19s 82.83MB 0.20s 78.86MB/s 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s kernel from 19/08/08 00:00:00: 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s 64*512602 0.43s 37.23MB 0.25s 63.57MB/s 128*512301 0.51s 31.39MB 0.26s 62.70MB/s 256*512150 0.47s 34.02MB 0.23s 69.06MB/s 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
top/ps CPU percentage broken on 7.1-PRERELEASE?
The CPU % displayed by top/ps for single processes seem to be broken here. E.g. for a simple shell loop: top starts displaying around 20% for bash. Within some seconds it converges to 0%. ps values seem to be consistent with top. The value in the time column seems to be correct. On every refresh it increases by 2s. last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 09:07:00 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free Swap: 1280M Total, 1280M Free PID USERNAMETHR PRI NICE SIZERES STATETIME WCPU COMMAND 19352 stefan1 990 4432K 2080K RUN 0:03 15.48% bash All other process are using 0% CPU. I did a buildworld/kernel yesterday to be sure everything is in sync. I have CURRENT on a different hard disk. Haven't seen the problem there. Are there any relevant fixes that weren't MFCed? Does anyone else see this? This is a single CPU i386 machine. -- Stefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 3 Oct 2008, Danny Braniss wrote: it more difficult than I expected. for one, the kernel date was missleading, the actual source update is the key, so the window of changes is now 28/July to 19/August. I have the diffs, but nothing yet seems relevant. on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' give the same throughput, which seem to point to UDP changes ... Can you post the network-numbers? so I ran some more test, these are for writes IO: OK, so it looks like this was almost certainly the rwlock change. What happens if you pretty much universally substitute the following in udp_usrreq.c: Currently Change to - - INP_RLOCK INP_WLOCK INP_RUNLOCK INP_WUNLOCK INP_RLOCK_ASSERTINP_WLOCK_ASSERT Robert N M Watson Computer Laboratory University of Cambridge server is a NetApp: kernel from 18/08/08 00:00:0 : /- UDP // TCP ---/ 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s 64*512602 0.20s 79.98MB 0.20s 78.44MB/s 128*512301 0.18s 86.51MB 0.22s 71.53MB/s 256*512150 0.19s 82.83MB 0.20s 78.86MB/s 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s kernel from 19/08/08 00:00:00: 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s 64*512602 0.43s 37.23MB 0.25s 63.57MB/s 128*512301 0.51s 31.39MB 0.26s 62.70MB/s 256*512150 0.47s 34.02MB 0.23s 69.06MB/s 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.5-prerelease and if_re - patches needed?
On Thu, Oct 02, 2008 at 10:25:42PM +0200, Torfinn Ingolfsen wrote: On Mon, 22 Sep 2008 11:10:23 +0900 Pyun YongHyeon [EMAIL PROTECTED] wrote: Due to lack of time and energy the change made in HEAD wasn't MFCed to RELENG_6 so you may still need some patch. stable/7 should have no such problems though. Does anybody happen to know which patch? Maybe the issue you're seeing comes from misuse of bus_dma(9) which was corrected in stable/7. But not MFC'ed to RELENG_6 I guess? Is therer a patch for RELENG_6 somewhere? I couldn't find spare time to regenerate patches for RELENG_6. Sorry. Maybe you can use if_re.c/if_rlreg.h in RELENG_7 with minor modification. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 3 Oct 2008, Danny Braniss wrote: it more difficult than I expected. for one, the kernel date was missleading, the actual source update is the key, so the window of changes is now 28/July to 19/August. I have the diffs, but nothing yet seems relevant. on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' give the same throughput, which seem to point to UDP changes ... Can you post the network-numbers? so I ran some more test, these are for writes IO: OK, so it looks like this was almost certainly the rwlock change. What happens if you pretty much universally substitute the following in udp_usrreq.c: Currently Change to - - INP_RLOCK INP_WLOCK INP_RUNLOCK INP_WUNLOCK INP_RLOCK_ASSERT INP_WLOCK_ASSERT I guess you were almost certainly correct :-) I did the global subst. on the udp_usrreq.c from 19/08, __FBSDID($FreeBSD: src/sys/netinet/udp_usrreq.c,v 1.218.2.3 2008/08/18 23:00:41 bz Exp $); and now udp is fine again! danny Robert N M Watson Computer Laboratory University of Cambridge server is a NetApp: kernel from 18/08/08 00:00:0 : /- UDP // TCP ---/ 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s 64*512602 0.20s 79.98MB 0.20s 78.44MB/s 128*512301 0.18s 86.51MB 0.22s 71.53MB/s 256*512150 0.19s 82.83MB 0.20s 78.86MB/s 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s kernel from 19/08/08 00:00:00: 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s 64*512602 0.43s 37.23MB 0.25s 63.57MB/s 128*512301 0.51s 31.39MB 0.26s 62.70MB/s 256*512150 0.47s 34.02MB 0.23s 69.06MB/s 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
cpghost wrote: If it's PATA, check the cabling, then check it again, and just to make sure, replace the cable even if the system used to work flawlessly in the past. I've had this on a few servers, but replacing the cables always fixed the problem for me. It's SATA - it's a 3ware 9500S-4LP controller. I can just hope it would have detect any drive problem (even if it would result because of bad cabeling). If not I don't know why I had a raid controller anyway ;) The only other disk drive I've on that system is an USB attached hdd for backup purpose... So I can't realy try having the swap somewhere else.. //nudel /c0 show all /c0 Driver Version = 3.60.04.003 /c0 Model = 9500S-4LP /c0 Available Memory = 112MB /c0 Firmware Version = FE9X 2.08.00.009 /c0 Bios Version = BE9X 2.03.01.052 /c0 Boot Loader Version = BL9X 2.02.00.001 /c0 Serial Number = D19004A5300589 /c0 PCB Version = Rev 019 /c0 PCHIP Version = 1.50 /c0 ACHIP Version = 3.20 /c0 Number of Ports = 4 /c0 Number of Drives = 4 /c0 Number of Units = 1 /c0 Total Optimal Units = 1 /c0 Not Optimal Units = 0 /c0 JBOD Export Policy = off /c0 Disk Spinup Policy = 1 /c0 Spinup Stagger Time Policy (sec) = 2 /c0 Cache on Degrade Policy = Follow Unit Policy Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy -- u0RAID-5OK - - 64K 698.461 ON OFF Port Status Unit SizeBlocksSerial --- p0 OK u0 232.88 GB 488397168 WD-WCANK1079272 p1 OK u0 232.88 GB 488397168 WD-WCANK1120378 p2 OK u0 232.88 GB 488397168 WD-WCANK1120936 p3 OK u0 232.88 GB 488397168 WD-WCANK1120805 Name OnlineState BBUReady StatusVolt Temp Hours LastCapTest --- bbu On Yes OKOK OK 25524-Aug-2008 //nudel -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 3 Oct 2008, Danny Braniss wrote: gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be helpfull. The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that the defaults work fine most of the time, so just use them. Turn the enable syscl on just before you begin a run, and turn it off immediately afterwards. Make sure to reset between reruns (rebooting to a new kernel is fine too!). as a side note, many years ago I checked out NFS/TCP and it was really bad, I even remember NetApp telling us to drop TCP, but now, things look rather better. Wonder what caused it. Well, the virtues of TCP become more apparent with higher network speeds, as the logic to fill pipes using TCP, manage flow control, etc, is a lot more sophisticated than what's in the RPC code for using UDP. The downsides to UDP are also becoming more apparent: as network speeds go up, fragmented UDP risks IP ID collisions which could lead to data corruption, or at the very least, dropped packets. We have changed the default for NFSv3 mounts to TCP in 8.x, and talked about doing it for 7.1; unfortunately the timing wasn't quite right, so it most likely will appear in 7.2. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top/ps CPU percentage broken on 7.1-PRERELEASE?
On Fri, Oct 03, 2008 at 10:03:13AM +0200, Stefan Ehmann wrote: The CPU % displayed by top/ps for single processes seem to be broken here. E.g. for a simple shell loop: top starts displaying around 20% for bash. Within some seconds it converges to 0%. ps values seem to be consistent with top. The value in the time column seems to be correct. On every refresh it increases by 2s. last pid: 19353; load averages: 0.99, 0.90, 0.76 up 0+00:37:29 09:07:00 119 processes: 2 running, 114 sleeping, 1 stopped, 2 zombie CPU: 98.5% user, 0.0% nice, 1.1% system, 0.4% interrupt, 0.0% idle Mem: 376M Active, 407M Inact, 144M Wired, 47M Cache, 110M Buf, 13M Free Swap: 1280M Total, 1280M Free PID USERNAMETHR PRI NICE SIZERES STATETIME WCPU COMMAND 19352 stefan1 990 4432K 2080K RUN 0:03 15.48% bash All other process are using 0% CPU. I did a buildworld/kernel yesterday to be sure everything is in sync. I have CURRENT on a different hard disk. Haven't seen the problem there. Are there any relevant fixes that weren't MFCed? Does anyone else see this? This is a single CPU i386 machine. Yes, my Java processes now run at 800% at times on my dual processor AMD64 system. -- Jonathan Chen [EMAIL PROTECTED] -- The Internet: an empirical test of the idea that a million monkeys banging on a million keyboards can produce Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
forget it about LOCK_PROFILING, I'm RTFM now :-) though some hints on values might be helpful. have a nice weekend, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 3 Oct 2008, Danny Braniss wrote: OK, so it looks like this was almost certainly the rwlock change. What happens if you pretty much universally substitute the following in udp_usrreq.c: Currently Change to - - INP_RLOCK INP_WLOCK INP_RUNLOCK INP_WUNLOCK INP_RLOCK_ASSERTINP_WLOCK_ASSERT I guess you were almost certainly correct :-) I did the global subst. on the udp_usrreq.c from 19/08, __FBSDID($FreeBSD: src/sys/netinet/udp_usrreq.c,v 1.218.2.3 2008/08/18 23:00:41 bz Exp $); and now udp is fine again! OK. This is a change I'd rather not back out since it significantly improves performance for many other UDP workloads, so we need to figure out why it's hurting us so much here so that we know if there are reasonable alternatives. Would it be possible for you to do a run of the workload with both kernels using LOCK_PROFILING around the benchmark, and then we can compare lock contention in the two cases? What we often find is that relieving contention at one point causes new contention at another point, and if the primitive used at that point handles contention less well for whatever reason, performance can be reduced rather than improved. So maybe we're looking at an issue in the dispatched UDP code from so_upcall? Another less satisfying (and fundamentally more difficult) answer might be something to do with the scheduler, but a bit more analysis may shed some light. Robert N M Watson Computer Laboratory University of Cambridge danny Robert N M Watson Computer Laboratory University of Cambridge server is a NetApp: kernel from 18/08/08 00:00:0 : /- UDP // TCP ---/ 1*512 38528 0.19s 83.50MB 0.20s 80.82MB/s 2*512 19264 0.21s 76.83MB 0.21s 77.57MB/s 4*512 9632 0.19s 85.51MB 0.22s 73.13MB/s 8*512 4816 0.19s 83.76MB 0.21s 75.84MB/s 16*512 2408 0.19s 83.99MB 0.21s 77.18MB/s 32*512 1204 0.19s 84.45MB 0.22s 71.79MB/s 64*512602 0.20s 79.98MB 0.20s 78.44MB/s 128*512301 0.18s 86.51MB 0.22s 71.53MB/s 256*512150 0.19s 82.83MB 0.20s 78.86MB/s 512*512 75 0.19s 82.77MB 0.21s 76.39MB/s 1024*512 37 0.19s 85.62MB 0.21s 76.64MB/s 2048*512 18 0.21s 77.72MB 0.20s 80.30MB/s 4096*512 9 0.26s 61.06MB 0.30s 53.79MB/s 8192*512 4 0.83s 19.20MB 0.41s 39.12MB/s 16384*512 2 0.84s 19.01MB 0.41s 39.03MB/s 32768*512 1 0.82s 19.59MB 0.39s 40.89MB/s kernel from 19/08/08 00:00:00: 1*512 38528 0.45s 35.59MB 0.20s 81.43MB/s 2*512 19264 0.45s 35.56MB 0.20s 79.24MB/s 4*512 9632 0.49s 32.66MB 0.22s 73.72MB/s 8*512 4816 0.47s 34.06MB 0.21s 75.52MB/s 16*512 2408 0.53s 30.16MB 0.22s 72.58MB/s 32*512 1204 0.31s 51.68MB 0.40s 40.14MB/s 64*512602 0.43s 37.23MB 0.25s 63.57MB/s 128*512301 0.51s 31.39MB 0.26s 62.70MB/s 256*512150 0.47s 34.02MB 0.23s 69.06MB/s 512*512 75 0.47s 34.01MB 0.23s 70.52MB/s 1024*512 37 0.53s 30.12MB 0.22s 73.01MB/s 2048*512 18 0.55s 29.07MB 0.23s 70.64MB/s 4096*512 9 0.46s 34.69MB 0.21s 75.92MB/s 8192*512 4 0.81s 19.66MB 0.43s 36.89MB/s 16384*512 2 0.80s 19.99MB 0.40s 40.29MB/s 32768*512 1 1.11s 14.41MB 0.38s 42.56MB/s ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 3 Oct 2008, Danny Braniss wrote: OK, so it looks like this was almost certainly the rwlock change. What happens if you pretty much universally substitute the following in udp_usrreq.c: Currently Change to - - INP_RLOCK INP_WLOCK INP_RUNLOCKINP_WUNLOCK INP_RLOCK_ASSERT INP_WLOCK_ASSERT I guess you were almost certainly correct :-) I did the global subst. on the udp_usrreq.c from 19/08, __FBSDID($FreeBSD: src/sys/netinet/udp_usrreq.c,v 1.218.2.3 2008/08/18 23:00:41 bz Exp $); and now udp is fine again! OK. This is a change I'd rather not back out since it significantly improves performance for many other UDP workloads, so we need to figure out why it's hurting us so much here so that we know if there are reasonable alternatives. Would it be possible for you to do a run of the workload with both kernels using LOCK_PROFILING around the benchmark, and then we can compare lock contention in the two cases? What we often find is that relieving contention at one point causes new contention at another point, and if the primitive used at that point handles contention less well for whatever reason, performance can be reduced rather than improved. So maybe we're looking at an issue in the dispatched UDP code from so_upcall? Another less satisfying (and fundamentally more difficult) answer might be something to do with the scheduler, but a bit more analysis may shed some light. gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be helpfull. as a side note, many years ago I checked out NFS/TCP and it was really bad, I even remember NetApp telling us to drop TCP, but now, things look rather better. Wonder what caused it. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I rebooted it today but despite pf_enable=YES being in /etc/rc.conf no rules got loaded during boot, despite pf itself having been enabled: router# pfctl -s rules router# pfctl -e -f /etc/pf.conf pfctl: pf already enabled [connection is closed due to new rules being loaded] router# pfctl -s rules scrub in all fragment reassemble [... lots of rules listed] Has anyone else seen this problem, or have I just missed something that's changed between 7.0 and 7.1 in the way pf works? I was seeing something similar on my own box which I just upgraded from a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no rules. pfctl -s info showed packet counters, but no interface stats (due to the rules not being loaded, e.g. no loginterface). kldstat showed pflog.ko and pf.ko loaded. If I did /etc/rc.d/pf start, the rules would loaded, and everything starts working as expected. I rebooted the box and saw the following on serial console, which I'm pretty sure is what's responsible for the breakage: Enabling pf. Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received cannot determine interface bandwidth for bge0, specify an absolute bandwidth altq not defined on bge0 altq not defined on bge0 /conf/ME/pf.conf:52: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:53: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:54: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded pf enabled I'd recommend you check your kernel console log on boot-up and see if anything is showing up there. I'm about to go digging to find out what's wrong with my ALTQ rules. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On Fri, Oct 03, 2008 at 04:17:03AM -0700, Jeremy Chadwick wrote:
On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote:
I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I
rebooted it today but despite pf_enable=YES being in /etc/rc.conf no
rules got loaded during boot, despite pf itself having been enabled:
router# pfctl -s rules
router# pfctl -e -f /etc/pf.conf
pfctl: pf already enabled
[connection is closed due to new rules being loaded]
router# pfctl -s rules
scrub in all fragment reassemble
[... lots of rules listed]
Has anyone else seen this problem, or have I just missed something
that's changed between 7.0 and 7.1 in the way pf works?
I was seeing something similar on my own box which I just upgraded from
a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no
rules. pfctl -s info showed packet counters, but no interface stats
(due to the rules not being loaded, e.g. no loginterface).
kldstat showed pflog.ko and pf.ko loaded.
If I did /etc/rc.d/pf start, the rules would loaded, and everything
starts working as expected.
I rebooted the box and saw the following on serial console, which I'm
pretty sure is what's responsible for the breakage:
Enabling pf.
Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received
cannot determine interface bandwidth for bge0, specify an absolute
bandwidth
altq not defined on bge0
altq not defined on bge0
/conf/ME/pf.conf:52: errors in queue definition
altq not defined on bge0
/conf/ME/pf.conf:53: errors in queue definition
altq not defined on bge0
/conf/ME/pf.conf:54: errors in queue definition
pfctl: Syntax error in config file: pf rules not loaded
pf enabled
Cross-posting to freebsd-pf (I'm sorry for doing this, but it needs
attention from both -pf and -stable).
I've figured out what the problem is. This is not good, and is
guaranteed to bite other people. I'd like to believe this is an
rc-related problem, but I'm not sure how to fix it.
The problem in my case:
The physical interfaces were brought online, but were still technically
offline (the switch and NIC PHY were taking some time to negotiate speed
and duplex). Boot messages:
bge0: link state changed to DOWN
bge1: link state changed to DOWN
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet 127.0.0.1 netmask 0xff00
bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING
inet XXX netmask 0xff80 broadcast X
ether 00:30:48:81:fc:8a
media: Ethernet autoselect (none)
status: no carrier
bge1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING
inet X netmask 0xff00 broadcast XXX
ether 00:30:48:81:fc:8b
media: Ethernet autoselect (none)
status: no carrier
Note that the interfaces are UP, not DOWN. Then the very next thing
seen on the console:
Starting pflog.
pflog0: promiscuous mode enabled
Enabling pf.
Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received
cannot determine interface bandwidth for bge0, specify an absolute
bandwidth
altq not defined on bge0
altq not defined on bge0
/conf/ME/pf.conf:52: errors in queue definition
altq not defined on bge0
/conf/ME/pf.conf:53: errors in queue definition
altq not defined on bge0
/conf/ME/pf.conf:54: errors in queue definition
pfctl: Syntax error in config file: pf rules not loaded
pf enabled
The error message about interface bandwidth is the key here. My ALTQ
rules use bandwidth percentage, not a static amount in bits:
altq on $ext_if cbq bandwidth 100% queue { std, blah, blah2 }
queue std bandwidth 95% cbq(default borrow)
queue blah bandwidth 384Kb
queue blah2bandwidth 384Kb
Since the PHY hadn't negotiated speed, pf was unable to determine what
the percentage really mapped to bandwidth/bit-wise.
If at all possible, pf should wait for the interfaces to come up fully
(that includes autonegotiation being completed; do we have framework for
this?) before starting.
I changed my rules to use a static speeds (100% -- 100Mb, and 95% --
95Mb), which appear to work, but after the 2nd reboot the speed/duplex
had been negotiated by the time pf had started, so I don't know if it
truly fixed anything. I don't know what pf will do if you say 100Mb
for an interface which has no link/speed defined yet. It may behave the
same way as shown above; I don't know.
This needs some thought and definitely a solution. Again, note that I'm
using RELENG_6, but I've a feeling this might bite RELENG_7 too.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On 12/23/-58 20:59, Bruce Cran wrote: div class=moz-text-flowedI recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I rebooted it today but despite pf_enable=YES being in /etc/rc.conf no rules got loaded during boot, despite pf itself having been enabled: router# pfctl -s rules router# pfctl -e -f /etc/pf.conf pfctl: pf already enabled [connection is closed due to new rules being loaded] router# pfctl -s rules scrub in all fragment reassemble [... lots of rules listed] Has anyone else seen this problem, or have I just missed something that's changed between 7.0 and 7.1 in the way pf works? Hi Bruce, # pfctl -sr | wc -l 81 # grep pf /etc/rc.conf pf_enable=YES pf_rules=/etc/Firewall/pf-ces.conf pflog_enable=YES this is from a very recent 7-STABLE box: # uname -a FreeBSD cesar.sz.vwsoft.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #46: Tue Sep 30 23:33:36 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CESAR i386 Do you mind to show me your rules? What does ``pfctl -gnf /path/to/your/rules'' give? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 3 Oct 2008, Danny Braniss wrote: gladly, but have no idea how to do LOCK_PROFILING, so some pointers would be helpfull. The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that the defaults work fine most of the time, so just use them. Turn the enable syscl on just before you begin a run, and turn it off immediately afterwards. Make sure to reset between reruns (rebooting to a new kernel is fine too!). in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof there 3 files: 7.1-100 host connected at 100 running -prerelease 7.1-1000same but connected at 1000 7.0-1000-stable with your 'patch' at 100 my benchmark didn't suffer from the profiling, average was about 9. at 1000 the benchmark got realy hit, average was around 12 for the patched, and 4 for the unpatched (less than at 100). danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb
On Wed, Sep 17, 2008 at 10:41:07PM +0200, I wrote: Hi! I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c commit (r183050, thanx! :) I was able to build a kernel that could kldload dtraceall on 7-stable amd64, but trying even simple things like dtrace -n tick-1sec only runs for a short time, or not at all, ending with $subject: # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m CPU IDFUNCTION:NAME 1 32125 :tick-1sec dtrace: processing aborted: Abort due to systemic unresponsiveness # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m dtrace: processing aborted: Abort due to systemic unresponsiveness # Looking around on the net I find that this is probably related to dtrace_gethrtime() (this box is SMP), which I see defined in sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c, and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386. The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into account which the one in sys/amd64/amd64/tsc.c doesn't, is there any particular reason this version is used? Also I don't see it in HEAD... I since found out two things: a) the version of dtrace_gethrtime() in sys/amd64/amd64/tsc.c is indeed not needed, and b) removing it still didn't fix my problem, stopping powerd then did, even with the original kernel. Doh! :) Anyway, I'm still pretty sure the #ifdef KDTRACE_HOOKS code in sys/amd64/amd64/tsc.c can go, the version of dtrace_gethrtime() in sys/cddl/dev/dtrace/amd64/dtrace_subr.c looks more correct at least... Thanx, Juergen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fxp performance with POLLING
Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 fxp0: Intel 82801DB (ICH4) Pro/100 Ethernet port 0xc800-0xc83f mem 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 # ifconfig fxp0 fxp0: flags=9843UP,BROADCAST,RUNNING,SIMPLEX,LINK0,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active BTW overall SAMBA performance still sucks on 7.1-pre as much as on RELENG_5 ...:( - 7.5 MB/s peak. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp performance with POLLING
On Friday 03 October 2008, Bartosz Stec wrote: Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? Yes. You don't want to use polling unless you set kern.hz to 1 or something in that range. If you have a NIC with interrupt moderation, polling should almost never be necessary. Note that polling can still be useful for routers, because it allows you to have a much more responsive system even when handling heavy network traffic. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB detach/attach hangs with 7.0-RELEASE and 7.1-PRERELEASE
USB support in the BIOS? What kind of support does the BIOS provide that you can disable? I'm only able to disable the USB device, but that'd turn it off completely :( Henrik. On Mon, Sep 29, 2008 at 10:05:02PM +0200, Ronald Klop wrote: On Mon, 29 Sep 2008 02:46:15 +0200, Bruce M Simpson [EMAIL PROTECTED] wrote: Hi, I've noticed some general instability with plugging in or removing USB devices with FreeBSD 7.x, even when the devices are not actively in use. I had this happen with umass and ucom devices 3 times today. The machine hangs solid, there are no obvious signs of a panic or trap to DDB. I can't provide backtraces unfortunately -- these hangs happen on both my laptop and desktop, and I usually have X running -- if I had more specific information, I'd open a PR. Again, there seems to be no reason why this should happen, the devices are off-the-shelf consumer items known to work with existing drivers, and have been repeatedly used in other OSes without these hangs happening; consider this an anecdotal report. [For some reason my IBM laptop will often not allow me to break into DDB on a driver related panic, and will just immediately reboot -- I lack free time to track down exactly why this could be. My desktop has a USB keyboard and this appears not to be supported by DDB, I ordered a PS/2 keyboard which hasn't arrived, but that's another story.] thanks BMS On my computer I had to disable USB support in the BIOS because it 'conflicted' with USB support of FreeBSD. FreeBSD still detects USB and all connected devices. Maybe this helps on your computer also. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp performance with POLLING
Pieter de Goeje wrote: On Friday 03 October 2008, Bartosz Stec wrote: Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? Yes. You don't want to use polling unless you set kern.hz to 1 or something in that range. HZ = 1000 or 2000 is fine for most purposes, at least up through T3 level bandwidth. For a home LAN or small business office of a half-dozen machines using DSL/Cable (~ 1-5 MBs up), even a P2-300 or VIA C3 600 at HZ=250 works OK as a firewall/router. The main thing that using polling does is that it adds a reasonably fixed amount of latency (ie, the poll interval) but gives solid processing performance even under heavy load, just as you say: If you have a NIC with interrupt moderation, polling should almost never be necessary. Note that polling can still be useful for routers, because it allows you to have a much more responsive system even when handling heavy network traffic. Note that he's got the link0 flag going, so that should mean he's using firmware with the fxp NIC which does interrupt moderation. Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On Fri, Oct 03, 2008 at 04:17:03AM -0700, Jeremy Chadwick wrote: On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote: I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I rebooted it today but despite pf_enable=YES being in /etc/rc.conf no rules got loaded during boot, despite pf itself having been enabled: router# pfctl -s rules router# pfctl -e -f /etc/pf.conf pfctl: pf already enabled [connection is closed due to new rules being loaded] router# pfctl -s rules scrub in all fragment reassemble [... lots of rules listed] Has anyone else seen this problem, or have I just missed something that's changed between 7.0 and 7.1 in the way pf works? I was seeing something similar on my own box which I just upgraded from a 150-day-old RELENG_6 to present RELENG_6. pfctl -s rules output no rules. pfctl -s info showed packet counters, but no interface stats (due to the rules not being loaded, e.g. no loginterface). kldstat showed pflog.ko and pf.ko loaded. If I did /etc/rc.d/pf start, the rules would loaded, and everything starts working as expected. I rebooted the box and saw the following on serial console, which I'm pretty sure is what's responsible for the breakage: Enabling pf. Oct 3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received cannot determine interface bandwidth for bge0, specify an absolute bandwidth altq not defined on bge0 altq not defined on bge0 /conf/ME/pf.conf:52: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:53: errors in queue definition altq not defined on bge0 /conf/ME/pf.conf:54: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded pf enabled I'd recommend you check your kernel console log on boot-up and see if anything is showing up there. I'm about to go digging to find out what's wrong with my ALTQ rules. I noticed the last time I rebooted my gateway to patch the latest v6 hole that vr0 (in my case) had not negotiated link by the time pf started (even tho its a static IP address, not DHCP). This meant that there was no link speed for altq to base its queueing on, and the entire pf load failed (I think). I changed my vr0 altq line to hardcode the speed at 100mbit and I think that should fix it Why this is an issue now and it wasn't previously I'm not sure. The current failure mode is certainly not helpful. I'm not sure if we should force pf to wait for link on altq interfaces or not. Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
NFSv4 ACL on RELENG_7?
Hello, A quick question: Is there an NFSv4 ACL patch available for testing on RELENG_7? (I have a quite busy machine on which I wanted to test-drive NFSv4 ACL.) Cheers, Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 3 Oct 2008, Danny Braniss wrote:
On Fri, 3 Oct 2008, Danny Braniss wrote:
gladly, but have no idea how to do LOCK_PROFILING, so some pointers would
be helpfull.
The LOCK_PROFILING(9) man page isn't a bad starting point -- I find that
the defaults work fine most of the time, so just use them. Turn the enable
syscl on just before you begin a run, and turn it off immediately
afterwards. Make sure to reset between reruns (rebooting to a new kernel
is fine too!).
in ftp://ftp.cs.huji.ac.il/users/danny/lock.prof
there 3 files:
7.1-100 host connected at 100 running -prerelease
7.1-1000same but connected at 1000
7.0-1000-stable with your 'patch'
at 100 my benchmark didn't suffer from the profiling, average was about 9.
at 1000 the benchmark got realy hit, average was around 12 for the patched,
and 4 for the unpatched (less than at 100).
Interesting. A bit of post-processing:
[EMAIL PROTECTED]:/tmp cat 7.1-1000 | awk -F' ' '{print $3 $9}' | sort -n |
tail -10
2413283 /r+d/7/sys/kern/kern_mutex.c:141
2470096 /r+d/7/sys/nfsclient/nfs_socket.c:1218
2676282 /r+d/7/sys/net/route.c:293
2754866 /r+d/7/sys/kern/vfs_bio.c:1468
3196298 /r+d/7/sys/nfsclient/nfs_bio.c:1664
3318742 /r+d/7/sys/net/route.c:1584
3711139 /r+d/7/sys/dev/bge/if_bge.c:3287
3753518 /r+d/7/sys/net/if_ethersubr.c:405
3961312 /r+d/7/sys/nfsclient/nfs_subs.c:1066
10688531 /r+d/7/sys/dev/bge/if_bge.c:3726
[EMAIL PROTECTED]:/tmp cat 7.0-1000 | awk -F' ' '{print $3 $9}' | sort -n |
tail -10
468631 /r+d/hunt/src/sys/nfsclient/nfs_nfsiod.c:286
501989 /r+d/hunt/src/sys/nfsclient/nfs_vnops.c:1148
631587 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1198
701155 /r+d/hunt/src/sys/nfsclient/nfs_socket.c:1258
718211 /r+d/hunt/src/sys/kern/kern_mutex.c:141
1118711 /r+d/hunt/src/sys/nfsclient/nfs_bio.c:1664
1169125 /r+d/hunt/src/sys/nfsclient/nfs_subs.c:1066
1222867 /r+d/hunt/src/sys/kern/vfs_bio.c:1468
3876072 /r+d/hunt/src/sys/netinet/udp_usrreq.c:545
5198927 /r+d/hunt/src/sys/netinet/udp_usrreq.c:864
The first set above is with the unmodified 7-STABLE tree, the second with a
reversion of read locking on the UDP inpcb. The big blinking sign of interest
is that the bge interface lock is massively contended in the first set of
output, and basically doesn't appear in the second. There are various reasons
bge could stand out quite so much -- one possibly is that previously, the udp
lock serialized all access to the interface from the send code, preventing the
send and receive paths from contending.
A few things to try:
- Let's look compare the context switch rates on the two benchmarks. Could
you run vmstat and look at the cpu cs line during the benchmarks and see how
similar the two are as the benchmarks run? You'll want to run it with
vmstat -w 1 and collect several samples per benchmark, since we're really
interested in the distribution rather than an individual sample.
- Is there any chance you could drop an if_em card into the same box and run
the identical benchmarks with and without LOCK_PROFILING to see whether it
behaves differently than bge when the patch is applied? if_em's interrupt
handling is quite different, and may significantly affect lock use, and
hence contention.
Thanks,
Robert N M Watson
Computer Laboratory
University of Cambridge
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On Fri, 3 Oct 2008 04:38:24 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: I've figured out what the problem is. This is not good, and is guaranteed to bite other people. I'd like to believe this is an rc-related problem, but I'm not sure how to fix it. The problem in my case: The physical interfaces were brought online, but were still technically offline (the switch and NIC PHY were taking some time to negotiate speed and duplex). Boot messages: My box is headless so I didn't see the startup messages until I attached a serial cable. It's a similar problem in my case, but caused because I'm firewalling an ADSL connection which uses PPP, and pf is being enabled before PPP has configured tun0: Setting hostname: router.draftnet. vr0: link state changed to DOWN dc0: link state changed to UP dc3: link state changed to UP lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff00 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2808VLAN_MTU,WOL_UCAST,WOL_MAGIC ether 00:40:63:e3:d1:b7 inet6 XX%vr0 prefixlen 64 tentative scopeid 0x1 inet X netmask 0xff00 broadcast XX media: Ethernet autoselect (none) status: no carrier dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:80:c8:c9:96:6d inet6 X%dc0 prefixlen 64 tentative scopeid 0x2 inet X netmask 0xff00 broadcast X media: Ethernet autoselect (100baseTX full-duplex) status: active dc3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:80:c8:c9:96:70 inet6 X%dc3 prefixlen 64 tentative scopeid 0x5 inet X netmask 0xff00 broadcast X media: Ethernet autoselect (100baseTX full-duplex) status: active Enabling pf. no IP address found for tun0 /etc/pf.conf:45: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded pf enabled Starting PPP profile: demonLoading /lib/libalias_cuseeme.so Loading /lib/libalias_ftp.so Loading /lib/libalias_irc.so Lodading /lib/libalcias_nbt.so Load1ing /lib/libalia:s_pptp.so Loadi ng /lib/libaliasl_skinny.so Loadiing /lib/libalians_smedia.so k. no IP address found for tun0 s /etc/pf.conf:45t: could not parsae host specificattion pfctl: Synetax error in con fig file: pf rulces not loaded ahdd net default: agateway tun0 Adnditional routingg options: IP gateeway=YES. dadd net :::0 .0.0.0: gateway t::1 add net ::0o.0.0.0: gateway ::1 net.inet6.iDp6.forwarding: 0O - 1 net.inet6W.ip6.accept_rtadNv: 0 - 0 dc2: link state changed to DOWN The messages following link state changed to DOWN indicate that all the interfaces are now properly configured with IP addresses, including the external ADSL tun0 and IPv6 gif0 interfaces. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrading to 7.x : make check-old
Folks: I have upgraded a server from 6.3 to 7.0. That went rather smoothly. I have a question about removing old libraries via make delete-old. Given the list of old libraries shown at the end of this URL: http://www.freebsddiary.org/upgrade-6.3-to-7.0.php Is that list more or less expected? From what I can tell, it's pretty safe to now do a make delete-old-libs. Do you concur? No, I won't hold you to it. I'm just looking for backup of my decision. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
make delete-old vs make-delete-libs
I'm wondering if these commands from /usr/src/Makefile are correctly described: # check-old - List obsolete directories/files/libraries. # check-old-dirs - List obsolete directories. # check-old-files - List obsolete files. # check-old-libs - List obsolete libraries. # delete-old - Delete obsolete directories/files/libraries. # delete-old-dirs - Delete obsolete directories. # delete-old-files- Delete obsolete files. # delete-old-libs - Delete obsolete libraries. From the above, it appears as if 'make delete-old' is the same as doing: make delete-old-dirs make delete-old-files make delete-old-libs Running the command indicates otherwise. In fact, make delete-old outputs: Removing old files (only deletes safe to delete libs) and: Old directories removed To remove old libraries run 'make delete-old-libs'. That indicates, to me, that only old files were deleted. No old libraries were touched. What's up here? Which is right? thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On 10/04/08 00:05, Bruce Cran wrote: On Fri, 3 Oct 2008 04:38:24 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: I've figured out what the problem is. This is not good, and is guaranteed to bite other people. I'd like to believe this is an rc-related problem, but I'm not sure how to fix it. The problem in my case: The physical interfaces were brought online, but were still technically offline (the switch and NIC PHY were taking some time to negotiate speed and duplex). Boot messages: My box is headless so I didn't see the startup messages until I attached a serial cable. It's a similar problem in my case, but caused because I'm firewalling an ADSL connection which uses PPP, and pf is being enabled before PPP has configured tun0: Setting hostname: router.draftnet. vr0: link state changed to DOWN dc0: link state changed to UP dc3: link state changed to UP lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff00 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2808VLAN_MTU,WOL_UCAST,WOL_MAGIC ether 00:40:63:e3:d1:b7 inet6 XX%vr0 prefixlen 64 tentative scopeid 0x1 inet X netmask 0xff00 broadcast XX media: Ethernet autoselect (none) status: no carrier dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:80:c8:c9:96:6d inet6 X%dc0 prefixlen 64 tentative scopeid 0x2 inet X netmask 0xff00 broadcast X media: Ethernet autoselect (100baseTX full-duplex) status: active dc3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:80:c8:c9:96:70 inet6 X%dc3 prefixlen 64 tentative scopeid 0x5 inet X netmask 0xff00 broadcast X media: Ethernet autoselect (100baseTX full-duplex) status: active Enabling pf. no IP address found for tun0 /etc/pf.conf:45: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded pf enabled Starting PPP profile: demonLoading /lib/libalias_cuseeme.so Loading /lib/libalias_ftp.so Loading /lib/libalias_irc.so Lodading /lib/libalcias_nbt.so Load1ing /lib/libalia:s_pptp.so Loadi ng /lib/libaliasl_skinny.so Loadiing /lib/libalians_smedia.so k. no IP address found for tun0 s /etc/pf.conf:45t: could not parsae host specificattion pfctl: Synetax error in con fig file: pf rulces not loaded ahdd net default: agateway tun0 Adnditional routingg options: IP gateeway=YES. dadd net :::0 .0.0.0: gateway t::1 add net ::0o.0.0.0: gateway ::1 net.inet6.iDp6.forwarding: 0O - 1 net.inet6W.ip6.accept_rtadNv: 0 - 0 dc2: link state changed to DOWN The messages following link state changed to DOWN indicate that all the interfaces are now properly configured with IP addresses, including the external ADSL tun0 and IPv6 gif0 interfaces. Bruce, looking into my crystal ball... ;) You seem to have a rule like: pass ... on tun0 from any to tun0 ... If you change that into: pass ... on tun0 from any to (tun0) ... pf will happily parse your rules and activate your firewall even while tun0 does not already have an IP address. You may also try to use rules naming an interface family instead of a single interface. Other than that suggestion, I may help you if you'll send me your rules (private mail is ok for me). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On Sat, 04 Oct 2008 00:40:45 +0200 Volker [EMAIL PROTECTED] wrote: You seem to have a rule like: pass ... on tun0 from any to tun0 ... If you change that into: pass ... on tun0 from any to (tun0) ... pf will happily parse your rules and activate your firewall even while tun0 does not already have an IP address. You may also try to use rules naming an interface family instead of a single interface. You're right - I mostly used lines with (tun0) but line 45 didn't have the brackets. I've just added them, rebooted and pf loaded the rules during boot. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On 10/04/08 01:22, Bruce Cran wrote: On Sat, 04 Oct 2008 00:40:45 +0200 Volker [EMAIL PROTECTED] wrote: You seem to have a rule like: pass ... on tun0 from any to tun0 ... If you change that into: pass ... on tun0 from any to (tun0) ... pf will happily parse your rules and activate your firewall even while tun0 does not already have an IP address. You may also try to use rules naming an interface family instead of a single interface. You're right - I mostly used lines with (tun0) but line 45 didn't have the brackets. I've just added them, rebooted and pf loaded the rules during boot. Well, sometimes my crystal ball works ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
