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
Hi, I will see what I can do when I come back from work. PF is based on ipfilter so having 3 is indeed a bit much. Chris 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? Regards, Gary ___ 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: panic bus_dma
On 2013-02-24 00:01, Konstantin Belousov wrote: On Sat, Feb 23, 2013 at 07:41:18PM -0600, cpet wrote: Seems like my issue was imposed by commit 246713 tested using 246712 boots tested using 246713 panics keeping all the current debug stuff made the system keep going but reset the 3ware removing all the debug info made the system instantly panic with latest rev 247203 panic: _bus_dmama_load_ccb Unsupported Func Code 0 rev 246713 I am very sorry that I did not develop my mentiferous abilities far enough in time of your report arrival, so we unfortunately need to resort to some burdensome methods of properly reporting an issue. Specify the exact driver you use, preferrably demonstrating the fragment of the verbose dmesg related to the controller attachment. Show exact printout on the console at the time of panic. The grep of the kernel sources for 'Unsupported Func Code' finds nothing. This is probably panic(_bus_dmamap_load_ccb: Unsupported func code %d) in the _bus_dmamap_load_ccb(). Show the backtrace from ddb and kgdb for the panic. Hi I will get the bt later tonight as i had to remember how to do it :) ___ 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
CURRENT rev 247203 fails to boot
CURRENT rev fails to boot even after updating world after bintuils patch. the rev that does work is 246703 which is whats booted up now. 3ware card is a 9650 8 port with latest fw but i dont think this is a fw/card issue as the said rev works fine. ___ 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
panic bus_dma
Seems like my issue was imposed by commit 246713 tested using 246712 boots tested using 246713 panics keeping all the current debug stuff made the system keep going but reset the 3ware removing all the debug info made the system instantly panic with latest rev 247203 panic: _bus_dmama_load_ccb Unsupported Func Code 0 rev 246713 Chris ___ 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
