Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 8/1/14, 3:39 PM, krad wrote: I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now since ipfw now has a 'nat' keyword you might say that is has changed in that 10 years. ___ 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: comments on vt as console...
On 1 August 2014 17:18, John-Mark Gurney wrote: > So, I decided to play around w/ vt after the recent UTF-8 discussion, > and noticed some issues w/ it... > > First, if you load the gallant font, things don't look very good... This > is probably because of the fact that I'm using the vga driver: > VT: running with driver "vga". Yes, this is an issue with vt_vga, and affects fonts other than a multiple of 8 pixels wide. It's pr191591. > Second, once one vty has the gallant font loaded, if you switch vty's, > it can occure that the new vty does not display ANY text.. The display > is mostly blank... > > Third, w/ the other font loaded, the border doesn't always properly > get cleared... > > Fourth, when switching screens, there is a brief flash of vertical > stripes before the new screen comes on... Can we do something to make > sure that this transition is clean? Either a completely blank screen, > or ideally, no blank screen, but the new text appearing? I think #2 and #4 are variations on the same issue, and only affect vt_vga as far as I know. Can you submit a PR for that issue, and one for #3? ___ 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: domain_add(xxx) after domainfinalize...
On 1 August 2014 16:42, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Fri, Aug 01, 2014 at 16:25 -0700: >> On 1 August 2014 15:55, Marko Zec wrote: >> > On Fri, 1 Aug 2014 15:42:30 -0700 >> > Adrian Chadd wrote: >> > >> >> I'd just make it a panic. :) >> > >> > Are you prepared to say goodbye to kldloading netgraph at runtime? >> >> Well, why is it saying that? is there actually a problem? > > Please read the thread. Thanks. I've read the thread. I wanted to see what the reactions are. The linked message thread has much more useful information than this thread. Ie, there's some table that isn't lock protected and likely should be. -a ___ 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: domain_add(xxx) after domainfinalize...
Adrian Chadd wrote this message on Fri, Aug 01, 2014 at 16:25 -0700: > On 1 August 2014 15:55, Marko Zec wrote: > > On Fri, 1 Aug 2014 15:42:30 -0700 > > Adrian Chadd wrote: > > > >> I'd just make it a panic. :) > > > > Are you prepared to say goodbye to kldloading netgraph at runtime? > > Well, why is it saying that? is there actually a problem? Please read the thread. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: domain_add(xxx) after domainfinalize...
On 1 August 2014 15:55, Marko Zec wrote: > On Fri, 1 Aug 2014 15:42:30 -0700 > Adrian Chadd wrote: > >> I'd just make it a panic. :) > > Are you prepared to say goodbye to kldloading netgraph at runtime? Well, why is it saying that? is there actually a problem? -a ___ 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: domain_add(xxx) after domainfinalize...
On Fri, 1 Aug 2014 15:42:30 -0700 Adrian Chadd wrote: > I'd just make it a panic. :) Are you prepared to say goodbye to kldloading netgraph at runtime? Marko > > -a > > > On 1 August 2014 15:21, John-Mark Gurney wrote: > > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 > > +0200: > >> Just what I've got in January 2011: > >> http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html > > > > Sadly, after three (or six+) years, it is clear that these bugs will > > not be fixed, and this warning message is not useful, since no one > > has stepped up to fix them.. > > > > btw, you might want to create a bug w/ the information you tracked > > down to hopefully help the person that decides to finally fix them, > > though I doubt they will ever be fixed as people apparently don't > > see bad behavior... > > > > Unless someone fixes the bugs in the next few days, I will commit > > the following patch: > > Index: uipc_domain.c > > === > > --- uipc_domain.c (revision 266964) > > +++ uipc_domain.c (working copy) > > @@ -227,15 +227,10 @@ > > printf("WARNING: attempt to domain_add(%s) before " > > "domaininit()\n", dp->dom_name); > > #endif > > -#ifdef notyet > > - KASSERT(domain_init_status < 2, > > - ("attempt to domain_add(%s) after domainfinalize()", > > - dp->dom_name)); > > -#else > > - if (domain_init_status >= 2) > > - printf("WARNING: attempt to domain_add(%s) after " > > - "domainfinalize()\n", dp->dom_name); > > -#endif > > + /* > > +* XXX - there are bugs WRT to adding domain after > > domain_finalize is > > +* called > > +*/ > > mtx_unlock(&dom_mtx); > > } > > > > > >> On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney > >> wrote: > >> > >> > So, I have a laptop that devd loads the bluetooth module every > >> > time.. > >> > > >> > This means I get the following error on every boot: > >> > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > >> > WARNING: attempt to domain_add(netgraph) after domainfinalize() > >> > > >> > Is there any real benefit to this warning? I just looked at the > >> > code, and the domain gets added despite the warning... > >> > > >> > Also, it looks like the pervious warning, we should just make > >> > that an if/panic since it's clearly a programming bug, or kill > >> > the ifndef INVARIANTS... > > > > -- > > John-Mark Gurney Voice: +1 415 225 > > 5579 > > > > "All that I will do, has been done, All that I have, has not." > > ___ > > 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" ___ 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: domain_add(xxx) after domainfinalize...
I'd just make it a panic. :) -a On 1 August 2014 15:21, John-Mark Gurney wrote: > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200: >> Just what I've got in January 2011: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html > > Sadly, after three (or six+) years, it is clear that these bugs will > not be fixed, and this warning message is not useful, since no one has > stepped up to fix them.. > > btw, you might want to create a bug w/ the information you tracked down > to hopefully help the person that decides to finally fix them, though > I doubt they will ever be fixed as people apparently don't see bad > behavior... > > Unless someone fixes the bugs in the next few days, I will commit the > following patch: > Index: uipc_domain.c > === > --- uipc_domain.c (revision 266964) > +++ uipc_domain.c (working copy) > @@ -227,15 +227,10 @@ > printf("WARNING: attempt to domain_add(%s) before " > "domaininit()\n", dp->dom_name); > #endif > -#ifdef notyet > - KASSERT(domain_init_status < 2, > - ("attempt to domain_add(%s) after domainfinalize()", > - dp->dom_name)); > -#else > - if (domain_init_status >= 2) > - printf("WARNING: attempt to domain_add(%s) after " > - "domainfinalize()\n", dp->dom_name); > -#endif > + /* > +* XXX - there are bugs WRT to adding domain after domain_finalize is > +* called > +*/ > mtx_unlock(&dom_mtx); > } > > >> On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney wrote: >> >> > So, I have a laptop that devd loads the bluetooth module every time.. >> > >> > This means I get the following error on every boot: >> > WARNING: attempt to domain_add(bluetooth) after domainfinalize() >> > WARNING: attempt to domain_add(netgraph) after domainfinalize() >> > >> > Is there any real benefit to this warning? I just looked at the code, >> > and the domain gets added despite the warning... >> > >> > Also, it looks like the pervious warning, we should just make that an >> > if/panic since it's clearly a programming bug, or kill the ifndef >> > INVARIANTS... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > 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: domain_add(xxx) after domainfinalize...
Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200: > Just what I've got in January 2011: > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html Sadly, after three (or six+) years, it is clear that these bugs will not be fixed, and this warning message is not useful, since no one has stepped up to fix them.. btw, you might want to create a bug w/ the information you tracked down to hopefully help the person that decides to finally fix them, though I doubt they will ever be fixed as people apparently don't see bad behavior... Unless someone fixes the bugs in the next few days, I will commit the following patch: Index: uipc_domain.c === --- uipc_domain.c (revision 266964) +++ uipc_domain.c (working copy) @@ -227,15 +227,10 @@ printf("WARNING: attempt to domain_add(%s) before " "domaininit()\n", dp->dom_name); #endif -#ifdef notyet - KASSERT(domain_init_status < 2, - ("attempt to domain_add(%s) after domainfinalize()", - dp->dom_name)); -#else - if (domain_init_status >= 2) - printf("WARNING: attempt to domain_add(%s) after " - "domainfinalize()\n", dp->dom_name); -#endif + /* +* XXX - there are bugs WRT to adding domain after domain_finalize is +* called +*/ mtx_unlock(&dom_mtx); } > On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney wrote: > > > So, I have a laptop that devd loads the bluetooth module every time.. > > > > This means I get the following error on every boot: > > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > > > Is there any real benefit to this warning? I just looked at the code, > > and the domain gets added despite the warning... > > > > Also, it looks like the pervious warning, we should just make that an > > if/panic since it's clearly a programming bug, or kill the ifndef > > INVARIANTS... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: domain_add(xxx) after domainfinalize...
Just what I've got in January 2011: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html Svata On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney wrote: > So, I have a laptop that devd loads the bluetooth module every time.. > > This means I get the following error on every boot: > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > Is there any real benefit to this warning? I just looked at the code, > and the domain gets added despite the warning... > > Also, it looks like the pervious warning, we should just make that an > if/panic since it's clearly a programming bug, or kill the ifndef > INVARIANTS... > > Index: uipc_domain.c > === > --- uipc_domain.c (revision 266964) > +++ uipc_domain.c (working copy) > @@ -227,15 +227,6 @@ > printf("WARNING: attempt to domain_add(%s) before " > "domaininit()\n", dp->dom_name); > #endif > -#ifdef notyet > - KASSERT(domain_init_status < 2, > - ("attempt to domain_add(%s) after domainfinalize()", > - dp->dom_name)); > -#else > - if (domain_init_status >= 2) > - printf("WARNING: attempt to domain_add(%s) after " > - "domainfinalize()\n", dp->dom_name); > -#endif > mtx_unlock(&dom_mtx); > } > > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > 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"
comments on vt as console...
So, I decided to play around w/ vt after the recent UTF-8 discussion, and noticed some issues w/ it... First, if you load the gallant font, things don't look very good... This is probably because of the fact that I'm using the vga driver: VT: running with driver "vga". and the default resolution is 640x480... The gallant font is probably much higher res, and when I load it, the text screen size drops to 53x21, and the text is all chopped off. This is probably due to bad calculation on scaling... Second, once one vty has the gallant font loaded, if you switch vty's, it can occure that the new vty does not display ANY text.. The display is mostly blank... Third, w/ the other font loaded, the border doesn't always properly get cleared... Fourth, when switching screens, there is a brief flash of vertical stripes before the new screen comes on... Can we do something to make sure that this transition is clean? Either a completely blank screen, or ideally, no blank screen, but the new text appearing? $ sysctl kern.vt kern.vt.enable_altgr: 1 kern.vt.debug: 0 kern.vt.deadtimer: 15 kern.vt.suspendswitch: 1 $ uname -a FreeBSD pciehp 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r267710M: Thu Jul 31 21:39:53 ICT 2014 jmg@pciehp:/usr/home/jmg/freebsd.pciehp/sys/amd64/compile/GENERIC amd64 Let me know if you need any more info. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
domain_add(xxx) after domainfinalize...
So, I have a laptop that devd loads the bluetooth module every time.. This means I get the following error on every boot: WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() Is there any real benefit to this warning? I just looked at the code, and the domain gets added despite the warning... Also, it looks like the pervious warning, we should just make that an if/panic since it's clearly a programming bug, or kill the ifndef INVARIANTS... Index: uipc_domain.c === --- uipc_domain.c (revision 266964) +++ uipc_domain.c (working copy) @@ -227,15 +227,6 @@ printf("WARNING: attempt to domain_add(%s) before " "domaininit()\n", dp->dom_name); #endif -#ifdef notyet - KASSERT(domain_init_status < 2, - ("attempt to domain_add(%s) after domainfinalize()", - dp->dom_name)); -#else - if (domain_init_status >= 2) - printf("WARNING: attempt to domain_add(%s) after " - "domainfinalize()\n", dp->dom_name); -#endif mtx_unlock(&dom_mtx); } -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
On 01.08.2014 20:59, Adrian Chadd wrote: Can you file a pr with this patch? Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316 Cheers, Jan ___ 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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Can you file a pr with this patch? https://bugs.freebsd.org/submit/ That way we don't lose track of it. Thanks! -a On 1 August 2014 11:48, Jan Kokemüller wrote: > Hi, > > >> Maybe this is a problem caused by a misdetected clock source? I've had >> this problem as well. > > > I've appended the patch I've been using to fix this problem on this Intel > Core2Duo T6570 processor. There are some model IDs hardcoded in the TSC > detection code that enable TSC even though it's not invariant here (no > TSC_INVARIANT bit set on the CPU). There is some quirk code further down > that disables TSC once again, but it only works for processors that have C3 > power states (the T6570 doesn't). I don't think any of this model checking > code is necessary, but maybe I'm wrong. > > Cheers, > Jan > > ___ > 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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi, Maybe this is a problem caused by a misdetected clock source? I've had this problem as well. I've appended the patch I've been using to fix this problem on this Intel Core2Duo T6570 processor. There are some model IDs hardcoded in the TSC detection code that enable TSC even though it's not invariant here (no TSC_INVARIANT bit set on the CPU). There is some quirk code further down that disables TSC once again, but it only works for processors that have C3 power states (the T6570 doesn't). I don't think any of this model checking code is necessary, but maybe I'm wrong. Cheers, Jan diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c index 2a6c81d..a30424e 100644 --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -57,7 +57,8 @@ int tsc_perf_stat; static eventhandler_tag tsc_levels_tag, tsc_pre_tag, tsc_post_tag; SYSCTL_INT(_kern_timecounter, OID_AUTO, invariant_tsc, CTLFLAG_RDTUN, -&tsc_is_invariant, 0, "Indicates whether the TSC is P-state invariant"); +&tsc_is_invariant, 0, +"Indicates whether the TSC is ACPI P-, C- and T-state invariant"); TUNABLE_INT("kern.timecounter.invariant_tsc", &tsc_is_invariant); #ifdef SMP @@ -272,9 +273,7 @@ probe_tsc_freq(void) switch (cpu_vendor_id) { case CPU_VENDOR_AMD: - if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0 || - (vm_guest == VM_GUEST_NO && - CPUID_TO_FAMILY(cpu_id) >= 0x10)) + if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0) tsc_is_invariant = 1; if (cpu_feature & CPUID_SSE2) { tsc_timecounter.tc_get_timecount = @@ -282,12 +281,7 @@ probe_tsc_freq(void) } break; case CPU_VENDOR_INTEL: - if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0 || - (vm_guest == VM_GUEST_NO && - ((CPUID_TO_FAMILY(cpu_id) == 0x6 && - CPUID_TO_MODEL(cpu_id) >= 0xe) || - (CPUID_TO_FAMILY(cpu_id) == 0xf && - CPUID_TO_MODEL(cpu_id) >= 0x3 + if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0) tsc_is_invariant = 1; if (cpu_feature & CPUID_SSE2) { tsc_timecounter.tc_get_timecount = @@ -554,20 +548,6 @@ init_TSC_tc(void) } /* - * We cannot use the TSC if it stops incrementing in deep sleep. - * Currently only Intel CPUs are known for this problem unless - * the invariant TSC bit is set. - */ - if (cpu_can_deep_sleep && cpu_vendor_id == CPU_VENDOR_INTEL && - (amd_pminfo & AMDPM_TSC_INVARIANT) == 0) { - tsc_timecounter.tc_quality = -1000; - tsc_timecounter.tc_flags |= TC_FLAGS_C3STOP; - if (bootverbose) - printf("TSC timecounter disabled: C3 enabled.\n"); - goto init; - } - - /* * We can not use the TSC in SMP mode unless the TSCs on all CPUs * are synchronized. If the user is sure that the system has * synchronized TSCs, set kern.timecounter.smp_tsc tunable to a ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
Cy Schubert wrote this message on Wed, Jul 23, 2014 at 09:18 -0700: > In message om> > , Adrian Chadd writes: > > On 18 July 2014 07:34, krad wrote: > > > that is true and I have not problem using man pages, however thats not the > > > way most of the world work and search engines arent exactly new either. We > > > should be trying to engage more people not less, and part of that is > > > reaching out. > > > > Then do the port and maintain it. > > > > The problem isn't the desire to keep things up to date, it's a lack of > > people who want that _and_ are willing/able to do it _and_ are funded > > somehow. > > Funding is the issue. Sure, some of us maintain software because a personal > need however without funding one has to fit maintaining software into > whatever time is left. For those of us who do this without funding you > manage to squeeze in an hour here or there. Then write a proposal and submit it to the Foundation.. If you don't ask for funding, it rarely shows up... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi! On 1 August 2014 11:18, Steve Wills wrote: > Hi, > > On Thu, Jul 31, 2014 at 06:22:27PM +0200, Anton Berezin wrote: >> Jan, >> >> On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote: >> > On 31.07.2014 16:21, Anton Berezin wrote: >> > >At the console, depressing and holding a key does not lead to auto-repeat. >> > > >> > >At the console, sometimes a key only appears on the terminal after another >> > >key is pressed. >> > >> > Maybe this is a problem caused by a misdetected clock source? I've had this >> > problem as well. >> > >> > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other >> > settings that are listed in kern.timecounter.choice and >> > kern.eventtimer.choice, such as HPET which works great for me. >> >> Setting both to HPET certainly helped the LA. I cannot check the keyboard >> input until tomorrow, but chances are that it is indeed the fix. > > Just wanted to throw in another datapoint, I had this issue too and setting > kern.eventtimer.timer=HPET alone solved it for me. Please throw this into a bug report ticket and poke mav@ about it. -a ___ 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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi, On Thu, Jul 31, 2014 at 06:22:27PM +0200, Anton Berezin wrote: > Jan, > > On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote: > > On 31.07.2014 16:21, Anton Berezin wrote: > > >At the console, depressing and holding a key does not lead to auto-repeat. > > > > > >At the console, sometimes a key only appears on the terminal after another > > >key is pressed. > > > > Maybe this is a problem caused by a misdetected clock source? I've had this > > problem as well. > > > > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other > > settings that are listed in kern.timecounter.choice and > > kern.eventtimer.choice, such as HPET which works great for me. > > Setting both to HPET certainly helped the LA. I cannot check the keyboard > input until tomorrow, but chances are that it is indeed the fix. Just wanted to throw in another datapoint, I had this issue too and setting kern.eventtimer.timer=HPET alone solved it for me. Steve pgpj6dqznjoLq.pgp Description: PGP signature
Re: local_unbound update corrupts network accessibility!
Am 01.08.2014 um 18:25 schrieb O. Hartmann: > > After the unbound update - or coinciding this update in CURRENT - I have > massive and > disturbing problems connecting to some sites, email servers and even the SVN > server of > FreeBSD (ports and src). > > For some name resoltions I receive > > Host xxx.xxx.de not found: 2(SERVFAIL), while another domain then gets > resolved without > problems. Are you using dnssec? Check http://dnssec.vs.uni-due.de/ ___ 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"
local_unbound update corrupts network accessibility!
After the unbound update - or coinciding this update in CURRENT - I have massive and disturbing problems connecting to some sites, email servers and even the SVN server of FreeBSD (ports and src). For some name resoltions I receive Host xxx.xxx.de not found: 2(SERVFAIL), while another domain then gets resolved without problems. The disturbing part is that this problem occured out of the blue and I connect it with the update of unbound. It doesn't matter wether I use the old configuration or use a stupid vanilla one. The blockage is also affecting Email. It takes a while until connections are made. Sites, which could not resolved in the first place, get resolved after minutes, but then the data transfer is bumpy or gets stuck. I need to fix this. Boxes with older CURRENT than FreeBSD 11.0-CURRENT #0 r269339: Thu Jul 31 20:47:17 CEST 2014 amd64 do not show this nasty behaviour. What is up with the system? I tried to follow the UPDATING, but there is nothing special about essential changes. oh signature.asc Description: PGP signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Aug 1, 2014, at 8:46, Mark Felder wrote: > I personally use pf for many reasons, spamd included. I don't think anyone > out there is interested in forking spamd to play ball with ipfw so we would > also be alienating these users who can't just change packet filters. Is there > even an equivalent to pfsync for ipfw? I didn't think so, but I could be > wrong... > > In the world of firewalls pf has been put on a quite a pedestal. OpenBSD > pushed it hard and it marketed it well; people found it both powerful and > easy to use which created a cult following and lots of word of mouth > advertising. I find it hard to agree with removing pf from FreeBSD because of > the existing userbase. If there was an experimental label on it I would find > its removal easier to swallow. I have remained silent on this for two reasons: 1. I am a consumer of FreeBSD. I am a sysadmin, I am NOT a coder and *I* would not want any code that *I* wrote in the kernel of an OS that I was running. I know my limitations. So I could not contribute to the development of pf in FreeBSD 2. Where I use packet filters on a host, and that is not very much, I tend to use ipfilter because in those case my needs are simple. For heavy duty (read: gateway) filtering I use commercial firewalls like the Checkpoint 600 series. So the inclusion or exclusion of pf has no direct effect on me. Having said all that, the reason I use FreeBSD over other open source OSes right now is that it is, in my opinion, the most “grown up” option. I have never seen Linux as an Enterprise tier OS due to a number of basic design decisions made by Linus and those around him. Illumos is very good, but fairly narrow in both it’s hardware support and feature set. I never took a long hard look at the other BSDs as FreeBSD was recommended by a friend and I liked what I found, ESPECIALLY the documentation in the Handbook. I have read a lot of arguments on both sides of the pf in FreeBSD debate over the past weeks. Realistically I think what it comes down to is whether there is someone, a person, an individual with the necessary skill set and drive and desire (and that can be motivated by funding) to take ownership of it and run with it. If there is not, then I think pf in FreeBSD dies. No matter how many people want it to continue, no matter if it is best for FreeBSD for it to continue. Without someone to take ownership of it, then even if it continues it will not be top quality, and having something in FreeBSD that is not top quality would be a mistake (IMHO). -- Paul Kraus p...@kraus-haus.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: Future of pf / firewall in FreeBSD ? - does it have one ?
In freebsd-questions Digest, Vol 530, Issue 5, Message: 1 On Thu, 31 Jul 2014 22:02:22 +1000 Da Rock wrote: > On 07/29/14 20:35, Gleb Smirnoff wrote: > > On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: > > M> |> imho, the root problem here is that an effort to implement a > > M> single > > M> |> feature improvement (multi-threading) has caused the FreeBSD > > M> version > > M> |> of pf to apparently reach a near-unmaintainable position in the > > M> |> FreeBSD community because improvements from OpenBSD can no longer > > M> be > > M> |> ported over easily. FreeBSD's pf has been put in a virtual > > M> |> isolation chamber due to the multi-threaded enhancement. > > M> |> > > M> |> Was it worth it? > > M> | > > M> |Yes. This happened *three times* in BSD land now. How much more > > M> |proof does it take to make that clear? > > M> |[snip] > > M> > > M> In this instance, more proof would consist of pf development not > > M> wallowing in inactivity. > > M> > > M> imo, tactical changes were implemented in pf without the strategic > > M> negative consequences affecting the decision process guiding the > > M> implementation of those tactical features.And that's backwards. > > M> Strategies direct tactics, not vice versa. > > > > I would strongly disagree with you. I would claim that directions > > I've put in pf in 2012 are strategically correct, while previous > > life of pf in FreeBSD was not. > > > > History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already > > outdated. It isn't possible otherwise. While Max spent time on porting > > some stable version, the OpenBSD moved forward. It was later updated > > again by Max, and again right after update it was outdated. I mean > > that people who a) believe that OpenBSD pf is the one true b) eager > > for bleeding edge version, these people simply cannot be satisfied. > > A porter needs to take latest stable version from OpenBSD and spend > > some time working on it. So, pf in FreeBSD was always "outdated", > > even before my SMP work on it. > > Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. > > In 2004 we've got 10 years of diverging developement between FreeBSD > > and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in > > 9.x is again outdated and introduces a number of bugs that were not > > present in 8.x (regressions). Most regressions didn't came from OpenBSD, > > but were artifacts of porting. Also, the number of #ifdefs in code > > became so unbearable that no one would want to go through code > > fixing bugs. > > > > In 2012 for me it was obvious that following this route is strategically > > incorrect. You are never "up to date". You need more efforts to port > > pf, and you yield in a port of worse and worse quality over time. > > > > So, in 2012 I put a lot of efforts to not only bring pf out of a > > single mutex, but also make it more native to FreeBSD. You can > > read this through commit logs. > > > > The net result is that we got our own pf, that can be maintained > > further. Unfortunately, still no person is seen on horizon who can > > take maintainership. > > That explains it rather well. Thank you for the enlightenment on this. Indeed. This potted history covers a lot of ground, and work, to most of which I've been largely oblivious. I've used ipfw since '98; it well suited my assembler background and perhaps overly orthogonal tendencies, and I found dummynet hugely useful for herding small networks of unruly cats, so I've felt no need to explore pf, nor ipfilter. > Without diminishing your efforts so far, what do you think about > pitching all efforts into IPFW to combine effort and reduce overhead of > maintaining separate firewalls in the core? Is there an advantage to > having our own pf? Quoting Gleb's response from a later message: > Is there any disadvantage keeping it? It is a plugin. It is optional > and loadable. I removed most additions to the network stack that live > outside netpfil/pf. > > Some people like it and use it. > > It is also the only tool to configure ALTQ now. I think each of those is sufficient reason for existence, as long as there's ongoing people - at least a few - who care enough about it. Maybe it needs to become 'fpf' and be happy to complete its forking? I can't imagine pf or ipfilter people deciding to work on ipfw. For one thing, ipfw has quite a few people working on aspects, development is conservatively ongoing, with no discernable shortage of volunteers. For another, I feel that there are distinct philosophical differences at the level of rule definition languages. From my little reading, pf uses more high-level symbolic language, where ipfw is relentlessly linear and closer to bare metal. Different people will be attracted to, and will be able to work most efficiently with, such different approaches. I've no idea how pf works at the kernel
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
July 31 2014 2:41 AM, "Darren Pilgrim" wrote: >> >> No. I believe pf should be removed from FreeBSD and efforts refocused >> on keeping ipfw up to date and feature complete. It makes more sense to >> look at what pf, ipf, nbtables, etc. are all doing as a source of ideas >> for what we can do with ipfw. A decade ago, there was justification for >> adding pf: at the time, ipfw lacked some major features. >> >> Ipfw has since caught up. I see no remaining value in having more than >> one packet filter in the base. Ipfw is more mature and less broken, so >> we should keep it and ditch the rest in the name of survival efficiency. >> pf is not simply replaceable in many environments. For example, people use it specifically for its integration with the spamd greylisting daemon. I think it's reasonable to assume they did so because the whole spam filtering stack performs better on FreeBSD than on OpenBSD. This was just recently mentioned on twitter: @ng_security Why was the pf ioctl needed buffer reduced in FreeBSD 10? I'm not able to load my full spamd blacklist anymore. @freebsd #spamd #pf https://twitter.com/ng_security/status/494982307905040384 I personally use pf for many reasons, spamd included. I don't think anyone out there is interested in forking spamd to play ball with ipfw so we would also be alienating these users who can't just change packet filters. Is there even an equivalent to pfsync for ipfw? I didn't think so, but I could be wrong... In the world of firewalls pf has been put on a quite a pedestal. OpenBSD pushed it hard and it marketed it well; people found it both powerful and easy to use which created a cult following and lots of word of mouth advertising. I find it hard to agree with removing pf from FreeBSD because of the existing userbase. If there was an experimental label on it I would find its removal easier to swallow. I think it's worth pointing out that nobody really wanted to maintain an incompatible fork of ZFS indefinitely either; it would be a monumental if not suicidal task. And who wants to deal with the bad PR about FreeBSD being years behind Illumos features or, *gasp*, even letting a native Linux implementation one-up us? People found a way to collaborate, OpenZFS movement was founded, and this is a mostly solved problem, OS nuances aside. I can appreciate that people seem to care more about their data than their packet filters and FreeBSD ZFS certainly moves a lot of servers and appliances furthering the userbase whether or not they're using FreeBSD or TrueOS or some other derivative. Let's continue to give people another reason to put FreeBSD in their datacenters. Let's try to compete in the firewall/packet filter space too. On a side note I'd also like to point out that FreeBSD has been advertising pf by listing it first in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html I'm sure there's a subliminal message being sent there, intentional or not. I don't want to see FreeBSD lose mindshare from its absence in a time where FreeBSD uptake seems to be rising thanks in part to bad decisions in the GNU/Linux camp. This feels like a solvable problem if funding and enthusiasm is put behind it. OpenBSD really sounds willing to collaborate if not just because they're tired of seeing neglected forks of one of their prized babies: FreeBSD, NetBSD, DragonFlyBSD, OSX, iOS... ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
------ From:"krad"; Date:2014??8??1??(??) 3:39 To:"Gleb Smirnoff"; Cc:"freebsd-current";"FreeBSD Questions"; Subject:Re: Future of pf / firewall in FreeBSD ? - does it have one ? I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now On 31 July 2014 14:41, Gleb Smirnoff wrote: > On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: > D> Without diminishing your efforts so far, what do you think about > D> pitching all efforts into IPFW to combine effort and reduce overhead of > D> maintaining separate firewalls in the core? Is there an advantage to > D> having our own pf? > > Is there any disadvantage keeping it? It is a plugin. It is optional > and loadable. I removed most additions to the network stack that live > outside netpfil/pf. > > Some people like it and use it. > > It is also the only tool to configure ALTQ now. > > -- > Totus tuus, Glebius. > ___ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-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: Future of pf / firewall in FreeBSD ? - does it have one ?
------ From:"krad"; Date:2014??8??1??(??) 3:39 To:"Gleb Smirnoff"; Cc:"freebsd-current";"FreeBSD Questions"; Subject:Re: Future of pf / firewall in FreeBSD ? - does it have one ? I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now On 31 July 2014 14:41, Gleb Smirnoff wrote: > On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: > D> Without diminishing your efforts so far, what do you think about > D> pitching all efforts into IPFW to combine effort and reduce overhead of > D> maintaining separate firewalls in the core? Is there an advantage to > D> having our own pf? > > Is there any disadvantage keeping it? It is a plugin. It is optional > and loadable. I removed most additions to the network stack that live > outside netpfil/pf. > > Some people like it and use it. > > It is also the only tool to configure ALTQ now. > > -- > Totus tuus, Glebius. > ___ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-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: Future of pf / firewall in FreeBSD ? - does it have one ?
I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now On 31 July 2014 14:41, Gleb Smirnoff wrote: > On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: > D> Without diminishing your efforts so far, what do you think about > D> pitching all efforts into IPFW to combine effort and reduce overhead of > D> maintaining separate firewalls in the core? Is there an advantage to > D> having our own pf? > > Is there any disadvantage keeping it? It is a plugin. It is optional > and loadable. I removed most additions to the network stack that live > outside netpfil/pf. > > Some people like it and use it. > > It is also the only tool to configure ALTQ now. > > -- > Totus tuus, Glebius. > ___ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-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"