Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
On Sat, Apr 13, 2013 at 09:43:14PM -0700, Gleb Kurtsou wrote:
On (22/03/2013 11:51), Shawn Webb wrote:
Hey All,
I'm not sure if this is a result of r248583 or a different commit, but I
hit a kernel panic when closing Chrome. I've linked to the info and
core.txt files below. If you need me to ship you the vmcore file, let me
know. It's 1.1GB in size.
Other than the pasted files, I'm not too sure where to go from here. If
there's any other info you need, please let me know. I'm a newb at
submitting this kind of stuff.
Paste of info file: http://ix.io/4Qo
Paste of core.txt file: http://ix.io/4Qp
Shawn, did you find workaround for the problem?
I've just upgraded to recent HEAD and see the same panic on closing
chrome. Switching back to r247601 just before Merge Capsicum overhaul
commit makes panic disappear.
I did receive Shawn's report some time ago, I even installed Chromium to
try to reproduce it, but it didn't crash for me yet.
If there are some easy, but reliable steps to reproduce it, like open
this webpage in tab 1, then this webpage in tab 2, then close tab 1
that would be great. This kernel coredump is not really useful, as we
this is legitimate case of decrementing reference counter. The problem
is that something decremented it earlier when it shouldn't or it wasn't
incremented somewhere. DTrace might be useful tool here if we could
instrument it to log backtrace of all increments and decrements done by
the Chromium processes.
~ # kgdb -n 1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
Unread portion of the kernel message buffer:
VNASSERT failed
0xfe0196700760: tag none, type VBAD
usecount 0, writecount 0, refcount 0 mountedhere 0
flags (VV_NOSYNC|VI_DOOMED)
lock type zfs: UNLOCKED
panic: No vop_advlock(0xfe0196700760, 0xff823adb9908)
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff823adb9740
kdb_backtrace() at kdb_backtrace+0x39/frame 0xff823adb97f0
vpanic() at vpanic+0x127/frame 0xff823adb9830
kassert_panic() at kassert_panic+0x136/frame 0xff823adb98a0
VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x92/frame 0xff823adb98d0
closef() at closef+0x9a/frame 0xff823adb9960
closefp() at closefp+0xa0/frame 0xff823adb99b0
amd64_syscall() at amd64_syscall+0x1f9/frame 0xff823adb9ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff823adb9ab0
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80aeaaa8a, rsp =
0x7ebf3f38, rbp = 0x7ebf3f50 ---
[...]
(kgdb) fr 0
#0 doadump (textdump=1) at pcpu.h:231
231 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) up
#1 0x804f5827 in kern_reboot (howto=260) at
/freebsd-src/local/sys/kern/kern_shutdown.c:447
447 doadump(TRUE);
(kgdb)
#2 0x804f5d36 in vpanic (fmt=value optimized out, ap=value
optimized out)
at /freebsd-src/local/sys/kern/kern_shutdown.c:754
754 kern_reboot(bootopt);
(kgdb)
#3 0x804f5bc6 in kassert_panic (fmt=value optimized out)
at /freebsd-src/local/sys/kern/kern_shutdown.c:642
642 vpanic(fmt, ap);
(kgdb)
#4 0x80747aa2 in VOP_ADVLOCK_APV (vop=value optimized out,
a=0xff823adb9908)
at vnode_if.c:2522
2522 VNASSERT(vop != NULL, a-a_vp, (No vop_advlock(%p, %p),
a-a_vp, a));
(kgdb)
#5 0x804b8eaa in closef (fp=0xfe014da8ccd0,
td=0xfe0014aea920) at vnode_if.h:1041
1041 vnode_if.h: No such file or directory.
in vnode_if.h
(kgdb)
#6 0x804b7030 in closefp (fdp=0xfe001c8c4800, fd=value
optimized out, fp=0xfe014da8ccd0,
td=0xfe0014aea920, holdleaders=value optimized out)
at /freebsd-src/local/sys/kern/kern_descrip.c:1136
1136 error = closef(fp, td);
(kgdb) p *fp
$5 = {f_data = 0xfe0196700760, f_ops = 0x80a477b8, f_cred =
0xfe0067907600,
f_vnode = 0xfe0196700760, f_type = 1, f_vnread_flags = 0, f_flag = 3,
f_count = 0, f_seqcount = 0,
f_nextoff = 16388, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0},
f_offset = 16388, f_label = 0x0}
(kgdb) p *fp
$6 = {f_data = 0xfe0196700760, f_ops = 0x80a477b8, f_cred =
0xfe0067907600,
f_vnode = 0xfe0196700760, f_type = 1, f_vnread_flags = 0, f_flag = 3,
f_count = 0, f_seqcount = 0,
f_nextoff = 16388, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0},
f_offset = 16388, f_label = 0x0}
(kgdb) p fp-f_vnode
$7 = (struct vnode *) 0xfe0196700760
(kgdb) p *fp-f_vnode
$8 = {v_tag = 0x807a3e35 none, v_op = 0x0, v_data =
Re: ipfilter(4) needs maintainer
On Fri, Apr 12, 2013 at 11:33:30PM -0700, Rui Paulo wrote: It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Realy? pf do FTP nat translation w/o contexst switching? Multiple GRE nat translation? I am use from ipfilter only ipnat. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
mirror site ftp3.za.freebsd.org
Hi For quite some time this mirror site has been unreachable. AFAICT, my ex colleagues who used to maintain it have moved on and it's now been left unmaintained. I left there in 2004 and Mark Murray who set it up left shortly thereafter. Perhaps it should be dropped from the mirror list. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Sun, Apr 14, 2013 at 07:55:21PM +0100, Joe Holden wrote: wishmaster wrote: --- Original message --- From: Gary Palmer gpal...@freebsd.org Date: 14 April 2013, 19:06:59 On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. Cheers, For non-nat ipfw is still superior in every way, numbered rules (think: scripts), dummynet, much faster than pf, syntax is a lot nicer and predictable... Does anyone even use ipf? it doesn't even work on Linux anymore, junk it and keep pf+ipfw, job done. m0n0wall uses ipfilter: http://m0n0.ch/wall/facts.php pgpHApUzGDDwu.pgp Description: PGP signature
Re: ipfilter(4) needs maintainer
Hello, Mark. You wrote 15 апреля 2013 г., 2:25:07: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Mark. You wrote 15 апреля 2013 г., 2:25:07: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! -- // Black Lion AKA Lev Serebryakov l...@freebsd.org Things like ftp-proxy(8) will need address translation even with IPv6. Also certain scrub options require a NAT like functionalities. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Hello, Kimmo. You wrote 15 апреля 2013 г., 14:26:40: MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! KP Things like ftp-proxy(8) will need address translation even with IPv6. ftp-proxy is solution to help IPv4 NAT. Why do we need it when every device could have routable IPv6? Of course, _every_ device should be protected by border firewall (stateful and IPv6-enabled), but FTP server should have special rules for it to allow traffic pass, not some proxy. And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:26:40: MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! KP Things like ftp-proxy(8) will need address translation even with IPv6. ftp-proxy is solution to help IPv4 NAT. Why do we need it when every device could have routable IPv6? Of course, _every_ device should be protected by border firewall (stateful and IPv6-enabled), but FTP server should have special rules for it to allow traffic pass, not some proxy. And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. You're forgetting set ups where outgoing traffic is controlled by filter rules, outgoing passive mode ftp needs help from the proxy to open holes for arbitrary ports. This is not limited to IPv4 and NAT. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! You disallow anonymization? NAT do anonymisation also. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:38 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! You disallow anonymization? NAT do anonymisation also. ___ Please stop it already, NAT has never done any real anonymisation. it's just one of the myths that just refuse to die. Use a real anonymiser like Tor if you want to keep your identity hidden. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Hello, Kimmo. You wrote 15 апреля 2013 г., 14:36:27: And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. KP You're forgetting set ups where outgoing traffic is controlled by KP filter rules, outgoing passive mode ftp needs help from the proxy to KP open holes for arbitrary ports. This is not limited to IPv4 and NAT. It could be done without IPv6 prefix mapping. Yes, firewall should have ability to expect some connections fro FTP commands (some flag on rule, for sure), but it is not prefix rewriting (there are some other protocols, which need similar treatment, like SIP)! I was shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own problems and complications, but one REALLY GOOD side of it, that we don't need NAT for it anymore! Some special tricks in firewall -- yes, maybe, for bad-designed, but widely-deployed application level protocols, but not address translations! I, personally, don't see any problems to enable all outbound connections for dedicated FTP server, though. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:36:27: And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. KP You're forgetting set ups where outgoing traffic is controlled by KP filter rules, outgoing passive mode ftp needs help from the proxy to KP open holes for arbitrary ports. This is not limited to IPv4 and NAT. It could be done without IPv6 prefix mapping. Yes, firewall should have ability to expect some connections fro FTP commands (some flag on rule, for sure), but it is not prefix rewriting (there are some other protocols, which need similar treatment, like SIP)! I was shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own problems and complications, but one REALLY GOOD side of it, that we don't need NAT for it anymore! Some special tricks in firewall -- yes, maybe, for bad-designed, but widely-deployed application level protocols, but not address translations! I, personally, don't see any problems to enable all outbound connections for dedicated FTP server, though. Server side is the easy part, no need for proxy because you know the passive mode data ports and you can open holes in your firewall using the known port numbers. I'm however talking about an ftp client behind a very restrictive firewall making an IPv6 connection an ftp server that uses passive mode data ports that can't be known in advance. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Hello, Kimmo. You wrote 15 апреля 2013 г., 14:47:24: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:47:24: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). Mmm, are you thinking of the way Linux iptables handles this scenario with a kernel mode helper? I don't think any of the three packet filters in FreeBSD has a functionality like that yet. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 02:50:23PM +0400, Lev Serebryakov wrote: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). Not heavy. But error-prone, yes. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! KP Things like ftp-proxy(8) will need address translation even with IPv6. ftp-proxy is solution to help IPv4 NAT. Why do we need it when every device could have routable IPv6? Of course, _every_ device should be protected by border firewall (stateful and IPv6-enabled), but FTP server should have special rules for it to allow traffic pass, not some proxy. And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. We are *way* too late in the game to completely avoid IPv6 NAT. Various flavors already exist in the form of RFCs, e.g. NPTv6: http://tools.ietf.org/html/rfc6296 Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 14.04.13 21:55, Joe Holden wrote: For non-nat ipfw is still superior in every way, numbered rules (think: scripts), dummynet, much faster than pf, syntax is a lot nicer and predictable... And, best of all, it still is buggy. At lest, it's tables handling is unusable. I have been very stubborn IPFW user for very long time, but finally gave up in favor of PF. Nothing like that ever since. I am also not convinced IPFW is any faster than PF. Daniel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:47:24: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). Mmm, are you thinking of the way Linux iptables handles this scenario with a kernel mode helper? I don't think any of the three packet filters in FreeBSD has a functionality like that yet. -Kimmo To elaborate on this, Linux iptables has a related qualifier for rules and the related traffic is identified by kernel mode helpers, ftp is one example for their use. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
On Mon, Apr 15, 2013 at 4:35 AM, Pawel Jakub Dawidek p...@freebsd.orgwrote: I did receive Shawn's report some time ago, I even installed Chromium to try to reproduce it, but it didn't crash for me yet. If there are some easy, but reliable steps to reproduce it, like open this webpage in tab 1, then this webpage in tab 2, then close tab 1 that would be great. This kernel coredump is not really useful, as we this is legitimate case of decrementing reference counter. The problem is that something decremented it earlier when it shouldn't or it wasn't incremented somewhere. DTrace might be useful tool here if we could instrument it to log backtrace of all increments and decrements done by the Chromium processes. Opening and closing tabs seems to be what does it for me. Try opening/closing tabs that have sites open that use Flash (like YouTube). It seems that I can go longer without a kernel panic these days, but it still does happen. I've pretty much switched to using Firefox. I was able to pinpoint the commit, but I wasn't able to pinpoint the actual code that causes the panic. For what it's worth, I'm also running ZFS on root. I'm not sure if that makes any difference. Pawel, can you give me some DTrace scripts to run? I have DTrace enabled on the machine. Thanks, Shawn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Monday April 15 2013 12:32:37 Lev Serebryakov wrote: And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. Fear not, NPT66 prefix translation is stateless, this is nothing like NAT44 / NAPT. On Monday April 15 2013 12:51:00 sth...@nethelp.no wrote: We are *way* too late in the game to completely avoid IPv6 NAT. Various flavors already exist in the form of RFCs, e.g. NPTv6: http://tools.ietf.org/html/rfc6296 Prefix translation is useful for SOHO or branch offices with more than one uplink, unless one wants to invest into AS and BGP or start building tunnels: http://blog.ioshints.info/2011/12/we-just-might-need-nat66.html Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
I have been very stubborn IPFW user for very long time, but finally gave up in favor of PF. Nothing like that ever since. I am also not convinced IPFW is any faster than PF. Hi Daniel, I know that measuring PPS for a firewall is not enought for comparing firewall performance (rfc3511 details lot's of the parameters, but on my smalldirty bench lab with an old server (one core Intel Pentium4 3.00GHz with a dual NIC 82546GB connected to the PCI-X Bus) I've got theses differences (value are in Kpps, small packet size) on FreeBSD 9.1: - forwarding-only: 405 Kpps - IPFW enabled: 320 Kpps - PF enabled: 274 Kpps IPFW was configured with only one line: add 3000 allow ip from any to any And PF with one line too: pass = On this simple test, IPFW is faster than PF regarding the forwarding rate. But without ipfwsync feature, IPFW is useless for our use case... Regards, Olivier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mirror site ftp3.za.freebsd.org
On Mon, 2013-04-15 at 11:22 +0200, Ian FREISLICH wrote: Hi For quite some time this mirror site has been unreachable. AFAICT, my ex colleagues who used to maintain it have moved on and it's now been left unmaintained. I left there in 2004 and Mark Murray who set it up left shortly thereafter. Perhaps it should be dropped from the mirror list. Ian Moving to clusteradm@ to poke at it. Sean signature.asc Description: This is a digitally signed message part
Re: ipfilter(4) needs maintainer
Ok, seems someone has taken the job. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
However it would of been better if said person asked me as I already offered to take it on but whatever. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message 8adc8f0961dd8f7972300837db7403ce.squir...@ma.sdf.org, c...@sdf.org writes: Ok, seems someone has taken the job. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_. Adrian On 15 April 2013 09:55, Cy Schubert cy.schub...@komquats.com wrote: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message 8adc8f0961dd8f7972300837db7403ce.squir...@ma.sdf.org, c...@sdf.org writes: Ok, seems someone has taken the job. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should be in the base system. Perhaps you can work on it as a port? Why do you want to work on something that people have been trying to remove since 2005? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8(B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Folks using Apache 2 ought to be interested in this DTrace module...
https://github.com/davepacheco/mod_usdt I've no time to port this but it ought to be straight forward and would be interesting to those serving up lots of Apache on FreeBSD. If someone wants to hack on it and have me review it, I can do that. Best, George signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ipfilter(4) needs maintainer
Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
To my knowledge it is already off by default and you need these options to enable it options IPFILTER options IPFILTER_LOG so to those that wish to have it removed from base, if it has a maintainer whats the trouble? On Mon, Apr 15, 2013 at 2:49 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). FYI, NetBSD has PF from OpenBSD: http://www.netbsd.org/docs/network/pf.html Also, they upgraded it to the latest GPL'ed sources recently (and moved to a different directory): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_with_tag=MAIN Now they have their own packet filter, called NPF: http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html They have more choices now. :-) Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRbFjtAAoJECXpabHZMqHOSFkIAK72iLtzb1py01/A+SbX8ejn hi5eh8ri6QQ2Kh4K96b/R5oHk5PoGNpc7xX7Kbp1wyJ2OrdNvAPnElwMDpPCjnRC rKPXiS25Km9D1e18E2pLB4iTweb/AOf87bGRz6skm3Rq0D4XOX9dwRndj1vqRxmH V/Rrdlzprx4EvDmgmfAfSZwGTGit6fVXqHHj5LtONURNKe4qAliVIdxB1vQFQBqB BnHF1gN7tIJVCrn+4yKSVsv6vqRSXp5LOIRBw2ooURKEkkKqVIapboEU+pGitN4g dbVZkoBol7V+LfqBBpsG7JH+OboUvdvWJ7hqeNtAV4YerBBBbePvx9D5iehmRUk= =/mAG -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Cy, good news that you volunteered to work on this! On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote: C The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't C done much with IPF while employed with Sun. Since then there has been some C development that is long overdue for HEAD. The problem is that v5.1.2 is under GPL. I'm afraid we should update to v4.1.34 only, and then stick to it. So the nearest TODO list is smth like: - update to v4.1.34 - cleanse old kernel APIs (timeout(9) at least) - fix VIMAGE - review open PRs (some might should be closed) - since we do not expect more imports, may be cleanse non-FreeBSD stuff from there? - maybe move it into sys/netpfil? Need to consult imp@ on that. License is very closed to BSD, but has some additions. C I'm not sure if I'd MFC it into 9 or not. This is up to you, but be adviced that head already differs from stable/9, for example network stack is entirely in network byte order. So merging would require a lot of attention and testing. C I did consider a port but given it would has to touch bits and pieces of C the source tree (/usr/src), a port would be messy and the decision was made C to work on importing it into base. Port isn't an option. IPFilter is too close to many kernel APIs, that can change quickly. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
After a source upgrade from 8.3-RELEASE to r249432 (HEAD)
It was pretty successful. All my 8.3 packages are still running very happily, though at some point I imagine I will have to update and recompile them. But ... When I press ENTER in the boot0 screen, I get the hyphen that will start spinning after a timeout and begin loading boot1 (which, as far as I know, I have not updated). boot1 (I think) presents me with a prompt that does not respond to key presses on the keyboard. It times out and continues loading anyway. At this stage, I am always presented with a manual mountroot: prompt, and I have to type ufs:/dev/ada0s1a to get any further. Does this just mean I should update the boot code? Presumably fdisk -B won't change anything. Should I just do bsdlabel -B? (It's an MBR disk.) Aside from this glitch, I'm very happy with how smoothly the update went. And I wouldn't be complaining, except that I'm tired of having to type ufs:/dev/ada0s1a every time I boot. -- George Mitchell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 20130415195544.gy76...@freebsd.org, Gleb Smirnoff writes: Cy, good news that you volunteered to work on this! On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote: C The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't C done much with IPF while employed with Sun. Since then there has been some C development that is long overdue for HEAD. The problem is that v5.1.2 is under GPL. I'm afraid we should update to v4.1.34 only, and then stick to it. So the nearest TODO list is smth like: - update to v4.1.34 - cleanse old kernel APIs (timeout(9) at least) - fix VIMAGE - review open PRs (some might should be closed) - since we do not expect more imports, may be cleanse non-FreeBSD stuff from there? - maybe move it into sys/netpfil? Need to consult imp@ on that. License is very closed to BSD, but has some additions. A small step in the right direction is a good thing. I'll run the patches by you first. The existing license isn't that BSD-friendly either, which is why it lives in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. A person can always load it anyway. C I'm not sure if I'd MFC it into 9 or not. This is up to you, but be adviced that head already differs from stable/9, for example network stack is entirely in network byte order. So merging would require a lot of attention and testing. C I did consider a port but given it would has to touch bits and pieces of C the source tree (/usr/src), a port would be messy and the decision was mad e C to work on importing it into base. Port isn't an option. IPFilter is too close to many kernel APIs, that can change quickly. Agreed. I looked at it a few months ago and determined that src is where it should be. (I put it aside, getting ACER WMI/ACPI working on my new Acer laptop was my priority at the time.) -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
The desire to remove it stems from the inability to give it adequate engineering service as the network stack evolves. Simply taking it out of a kernel config file doesn't address that problem at all. If it's going to stay in FreeBSD at all, it needs to be maintained. This could be set about a fair amount of stuff in FreeBSD, but IPFilter stands out since there's a high rate of needed change happening in the network stack, and it shouldn't be left to rot nor to be a stumbling block for those changes. Scott On Apr 15, 2013, at 12:49 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8(B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentions from well meaning people. What is your timeline for getting it back into shape and re-integrating yourself into the committer community? Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
It was pointed out to me that Darren Reed has changed licenses from his IP Filter license that's been in IPF since 2005 or so, when he joined Sun, to GPLv2 (probably when Darren left when Oracle took over Sun). Given that IPF already lives in src/contrib and src/sys/contrib due to the 2005 license change, would that be a problem? If it's OK then I'll maintain it in src. If not then a port is in order. Having said that, a port would be messy as IPF's own install scripts update src/sys/netinet, among other locations. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message d6ade9c6-868a-4524-a6d7-4eb88f9d6...@yahoo.com, Scott Long writes: The desire to remove it stems from the inability to give it adequate engineer ing service as the network stack evolves. Simply taking it out of a kernel confi g file doesn't address that problem at all. If it's going to stay in FreeBSD at all , it needs to be maintained. This could be set about a fair amount of stuff in Fr eeBSD, but IPFilter stands out since there's a high rate of needed change happening in the network stack, and it shouldn't be left to rot nor to be a stumbling bloc k for those changes. Scott On Apr 15, 2013, at 12:49 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrot e: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55ãCy Schubert cy.schub...@komquats.com ã®ã¡ãã»ã¼ã¸: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was mad e to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longes t of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 15, 2013, at 1:27 PM, Cy Schubert cy.schub...@komquats.com wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). I would assume that the license change would be OK, especially since the other option is to remove it (or let it continue to rot and be an eyesore) but I'll defer to those like Gleb and Rui with a more vested interest in it. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 516c58ed.40...@freebsd.org, Jung-uk Kim writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). FYI, NetBSD has PF from OpenBSD: http://www.netbsd.org/docs/network/pf.html Also, they upgraded it to the latest GPL'ed sources recently (and moved to a different directory): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_wi th_tag=MAIN Now they have their own packet filter, called NPF: http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html They have more choices now. :-) I'm always (or usually) one for more than fewer choices. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote: c However it would of been better if said person asked me as I already c offered to take it on but whatever. More manpower - the better. Why can't you work together? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 01:32:48PM -0600, Scott Long wrote: S Given that IPF already lives in src/contrib and src/sys/contrib, would the S change in License from Darren Reed's own not so BSD friendly IPF license to S GPLv2 be of concern. I recall there was a lot of concern over IPF's license S change at the time. (FreeBSD moved it to contrib while OpenBSD removed it S completely and wrote PF -- I'm not sure what NetBSD did). S S I would assume that the license change would be OK, especially since the other S option is to remove it (or let it continue to rot and be an eyesore) but I'll defer to those like S Gleb and Rui with a more vested interest in it. I'm not a licensing guru, so I can't tell whether GPL ipfilter can live in src/ and if it can, where should it be. So I expect someone else to comment on licensing. My personal, biased towards BSD, wish, is to import only the last BSD-licensed version, move it out of contrib to netpfil, remove zillions of compatibility (towards other OSes) code and just maintain it. Maintaining means fixing bugs and catching up on kernel changes. We can ask Darren whether we can switch the license to pure BSD. Since he himself switched the entire license to GPL, the insisting on the following clause seems strange, and expect he won't insist on it. The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied, in part or in whole, and put under another distribution licence [including the GNU Public Licence.] -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD)
On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: that does not respond to key presses on the keyboard. It times out and continues loading anyway. At this stage, I am always presented with a manual mountroot: prompt, and I have to type ufs:/dev/ada0s1a to get any further. Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? Sean signature.asc Description: This is a digitally signed message part
Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@
O. Hartmann ohart...@zedat.fu-berlin.de writes: Trying to recompile converters/libiconv on FreeBSD 10.0-CUR/r49438 (with bran new CLANG 3.3) results with the errors below. This error shows up on boxes having FBSD 10 and X11. It doesn't show up on those boxes running without a full X11 (that is the only difference I can figure out at the moment since the different systems share a lot of configuration stuff, having different CPU types (C2D, Sandy-Bridge, Ivy-Bridge) but nothing I can figure out as the source of the strange behaviour and error). [...] converters/libiconv: cc -DHAVE_CONFIG_H -DEXEEXT=\\ -I. -I.. -I../lib -I../intl -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1-O2 -pipe -O3 -march=native -fno-strict-aliasing -c areadlink.c In file included from areadlink.c:27: In file included from ./careadlinkat.h:23: In file included from ./fcntl.h:62: ./unistd.h:694:5: error: invalid token at start of a preprocessor expression #if @GNULIB_EUIDACCESS@ ^ 1 error generated. Maybe -O3 overoptimizes regex in libc e.g., $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' #if @GNULIB_EUIDACCESS@ $ echo 'xxx' | sed 's/xxx//' xxx ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD)
On 04/15/13 18:09, Sean Bruno wrote: On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: that does not respond to key presses on the keyboard. It times out and continues loading anyway. At this stage, I am always presented with a manual mountroot: prompt, and I have to type ufs:/dev/ada0s1a to get any further. Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? Sean Yes: # DeviceMountpoint FStype Options Dump Pass# /dev/ada0s1bnoneswapsw 0 0 /dev/ada0s1a/ ufs rw 1 1 [...] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD)
On Tue, Apr 16, 2013 at 1:44 AM, George Mitchell george+free...@m5p.com wrote: On 04/15/13 18:09, Sean Bruno wrote: On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: that does not respond to key presses on the keyboard. It times out and continues loading anyway. At this stage, I am always presented with a manual mountroot: prompt, and I have to type ufs:/dev/ada0s1a to get any further. Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? Sean Yes: # DeviceMountpoint FStype Options Dump Pass# /dev/ada0s1bnoneswapsw 0 0 /dev/ada0s1a/ ufs rw 1 1 [...] Change the order so that the root device is the first in /etc/fstab. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 20130415212826.ga76...@freebsd.org, Gleb Smirnoff writes: On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote: c However it would of been better if said person asked me as I already c offered to take it on but whatever. Sorry, I didn't see your posting. I had a permissions issue on my gateway which caused the loss of a few emails (still sorting through the list of bounces). More manpower - the better. Why can't you work together? I don't mind working with others. I know there's more than enough to keep everyone busy. My main goal is to make sure IPF doesn't disappear nor go into disrepair and to make sure it's well maintained. Let's work together. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD)
On 04/15/13 18:52, Kimmo Paasiala wrote: On Tue, Apr 16, 2013 at 1:44 AM, George Mitchell george+free...@m5p.com wrote: On 04/15/13 18:09, Sean Bruno wrote: On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: that does not respond to key presses on the keyboard. It times out and continues loading anyway. At this stage, I am always presented with a manual mountroot: prompt, and I have to type ufs:/dev/ada0s1a to get any further. Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? Sean Yes: # DeviceMountpoint FStype Options Dump Pass# /dev/ada0s1bnoneswapsw 0 0 /dev/ada0s1a/ ufs rw 1 1 [...] Change the order so that the root device is the first in /etc/fstab. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I tried that and there was no change. I still get the mountroot: prompt and have to type ufs:/dev/ada0s1a. -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD)
On Mon, Apr 15, 2013 at 03:58:26PM -0400, George Mitchell wrote: It was pretty successful. All my 8.3 packages are still running very happily, though at some point I imagine I will have to update and recompile them. But ... When I press ENTER in the boot0 screen, I get the hyphen that will start spinning after a timeout and begin loading boot1 (which, as far as I know, I have not updated). boot1 (I think) presents me with a prompt that does not respond to key presses on the keyboard. It times out and continues loading anyway. At this stage, I am always presented with a manual mountroot: prompt, and I have to type ufs:/dev/ada0s1a to get any further. I ran into this too. It was caused by a problem in r249408 and is fixed as of r249436. Updating your kernel to something beyond r249435 should make this go away. -Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD)
On 4/15/2013 7:50 PM, George Mitchell wrote: I tried that and there was no change. I still get the mountroot: prompt and have to type ufs:/dev/ada0s1a. -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org What if you change it to ad0 instead of ada0? I wonder if the legacy aliases isn't being set properly, or something related to that. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Last commit to HEAD
Okay I must be loosing it since the change over to svn, and loosing cvsup where can i find the last commit to HEAD ? and is it correct to use svn co http://svn.freebsd.org/base/head/ for 10.0-CURRENT srcs making the last commit rev 249529 and as for 9.x i thought releng was what brought updates to the 9 tree so why stable look like theres more current work, or is that going to become the life of 9.2 trying to refresh my memory here! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Last commit to HEAD
On Mon, Apr 15, 2013 at 09:48:20PM -0400, Outback Dingo wrote: Okay I must be loosing it since the change over to svn, and loosing cvsup where can i find the last commit to HEAD ? A couple of Web-oriented sources of information: * http://docs.freebsd.org/mail/current/svn-src-head.html, which (as of this writing) refers to Apr 15 Andrey V. Elsukov svn commit: r249528 - head/sys/netinet6. * http://svnweb.freebsd.org/base/head/, which (again, as of this writing) mentions Directory revision:249528 (of 249529). and is it correct to use svn co http://svn.freebsd.org/base/head/ for 10.0-CURRENT srcs Mostly, though we now have some official mirrors, as well; you might want to consider using one of those. And per http://www.freebsd.org/doc/en/articles/committers-guide/article.html#subversion-primer, https is recommended for anonymous checkout, e.g.: svn co https://svn0.us-west.FreeBSD.org/base/head /usr/src making the last commit rev 249529 As of this writing, that was the last commit to the src repository. However, that commit was to the user part of the repo, not to head. (Ref. http://svnweb.freebsd.org/base/.) and as for 9.x i thought releng was what brought updates to the 9 tree releng/* is equivalent to the old RELENG_* CVS branches -- that is, RELEASE_* + patches/commits to address security advisories. This is *not* what you want for new features (such as support for a device that wasn't supported in RELEASE). so why stable look like theres more current work, or is that going to become the life of 9.2 That's exactly the same as it was under CVS: stable/* is a development branch, and that *does* get new features (ideally, all MFCed from head), and (as of this writing) stable/9 is where code is committed that will eventually become release/9.2.0, then releng/9.2. trying to refresh my memory here! I hope that helps a bit. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpC5at9wQaBC.pgp Description: PGP signature
Re: Last commit to HEAD
On Mon, Apr 15, 2013 at 10:17 PM, David Wolfskill da...@catwhisker.orgwrote: On Mon, Apr 15, 2013 at 09:48:20PM -0400, Outback Dingo wrote: Okay I must be loosing it since the change over to svn, and loosing cvsup where can i find the last commit to HEAD ? A couple of Web-oriented sources of information: * http://docs.freebsd.org/mail/current/svn-src-head.html, which (as of this writing) refers to Apr 15 Andrey V. Elsukov svn commit: r249528 - head/sys/netinet6. * http://svnweb.freebsd.org/base/head/, which (again, as of this writing) mentions Directory revision:249528 (of 249529). and is it correct to use svn co http://svn.freebsd.org/base/head/ for 10.0-CURRENT srcs Mostly, though we now have some official mirrors, as well; you might want to consider using one of those. And per http://www.freebsd.org/doc/en/articles/committers-guide/article.html#subversion-primer , https is recommended for anonymous checkout, e.g.: svn co https://svn0.us-west.FreeBSD.org/base/head /usr/src making the last commit rev 249529 As of this writing, that was the last commit to the src repository. However, that commit was to the user part of the repo, not to head. (Ref. http://svnweb.freebsd.org/base/.) and as for 9.x i thought releng was what brought updates to the 9 tree releng/* is equivalent to the old RELENG_* CVS branches -- that is, RELEASE_* + patches/commits to address security advisories. This is *not* what you want for new features (such as support for a device that wasn't supported in RELEASE). so why stable look like theres more current work, or is that going to become the life of 9.2 That's exactly the same as it was under CVS: stable/* is a development branch, and that *does* get new features (ideally, all MFCed from head), and (as of this writing) stable/9 is where code is committed that will eventually become release/9.2.0, then releng/9.2. trying to refresh my memory here! I hope that helps a bit. Peace, david Yupp Thanks for the refresher, im good now! -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
On (15/04/2013 10:35), Pawel Jakub Dawidek wrote: On Sat, Apr 13, 2013 at 09:43:14PM -0700, Gleb Kurtsou wrote: On (22/03/2013 11:51), Shawn Webb wrote: Hey All, I'm not sure if this is a result of r248583 or a different commit, but I hit a kernel panic when closing Chrome. I've linked to the info and core.txt files below. If you need me to ship you the vmcore file, let me know. It's 1.1GB in size. Other than the pasted files, I'm not too sure where to go from here. If there's any other info you need, please let me know. I'm a newb at submitting this kind of stuff. Paste of info file: http://ix.io/4Qo Paste of core.txt file: http://ix.io/4Qp Shawn, did you find workaround for the problem? I've just upgraded to recent HEAD and see the same panic on closing chrome. Switching back to r247601 just before Merge Capsicum overhaul commit makes panic disappear. I did receive Shawn's report some time ago, I even installed Chromium to try to reproduce it, but it didn't crash for me yet. I could send you chrome binary I'm using. It's a outdated chromium-22.0.1229.92. If there are some easy, but reliable steps to reproduce it, like open this webpage in tab 1, then this webpage in tab 2, then close tab 1 that would be great. This kernel coredump is not really useful, as we this is legitimate case of decrementing reference counter. The problem is that something decremented it earlier when it shouldn't or it wasn't incremented somewhere. DTrace might be useful tool here if we could instrument it to log backtrace of all increments and decrements done by the Chromium processes. I'll try to reproduce it in vm.. which is not that easy because virtualbox kmod needs patching to work on month old CURRENT and there is no binary packages to install vm in the first place. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
