Re: Traditional cpp
On 2012-11-10 12:49, Dimitry Andric wrote: On 2012-11-10 07:46, Greg 'groggy' Lehey wrote: On Friday, 9 November 2012 at 13:52:24 +0100, Dimitry Andric wrote: ... Looks like yet another cpp -traditional abuse. Use or abuse? Abuse, definitely. :-) A C Preprocessor is clearly meant to preprocess C, not arbitrary text files. Hear, hear! :) You can see the problem of this approach, when you try to use another traditional preprocessor, like ports/devel/ucpp, for tools like Imake. Niclas Zeising can probably tell some interesting stories about this. Any subtly different spacing, token parsing behaviour, etc. tend to break those tools. They are basically relying on the specifics of the GNU cpp implementation. I have not tried imake, but when using ucpp for other parts of the xorg bundle, most notably libX11, things broke. ucpp passed the configure check, but when used to format text files it does not seem to work the same as gnu cpp (unless you have to add some sort of command line flag that I'm unaware of). This had the unfortunate effect that locales in xorg, amongst other things, stopped working. What I ended up doing to get the xorg ports to build (at least the ports pulled in by the xorg meta port) was to simply remove the configure check for cpp -traditional, and proceed anyway. The only ill effects I've seen so far is that whitespace in cpp generated files get mangled. I have not noticed any functional problems though. For details, see ports r301687: http://svnweb.freebsd.org/ports?view=revisionrevision=301687 As a side note, it seems that xorg upstream is moving away from using cpp to generate manuals, at least. For the case of imake the issue might be harder to resolve. I don't know any imake internals, and I have never used it, but it seem to me that imake uses cpp to generate and pre-process makefiles. This might be harder to fix by replacing cpp with sed/awk wizardry. It might be more worthwhile to try to fix the port that use imake to use something else, but I have no clue about how big an undertaking this would be. In any case, it's not the only one. In the Good Old Days people did things like that. So, it seems, does imake, and I'm sure others will come out of the woodwork. Clang will most likely never support traditional preprocessing. OK. It is probably better to just use sed or awk for this kind of trickery. I'm not sure that's the way to go. It's more work than it's worth. What we really need is a traditional cpp. That's not difficult: there's one in 4.3BSD (all 32 kB of source). OpenBSD also had one, though it's gone now, so presumably that one has a clean license. Both appear to be from pcc. Should we import it into the tree as, say, tradcpp? Please check with Niclas and the other ports guys who have been wrestling with exactly this issue for some time. They may have lots of good suggestions. I have not tested anything but gnu cpp, clang cpp and ucpp. I'm not against the import of a traditional cpp, but to me it seems it might be better to just fix the cpp abuse altogether. In any case, the cpp -traditional replacement *must* be bug-for-bug compatible with gcc cpp, which I've been told is quite undocumented. Regards! -- Niclas ___ 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: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found
On 11/12/12 02:19, Steve Kargl wrote: On Sun, Nov 11, 2012 at 10:41:41PM +0100, O. Hartmann wrote: I replaced lang/gcc46 by lang/gcc47, since gcc46 doesn't build anymore on the FreeBSD 10.0-CURRENT in question. I have a small f77 program, which built well with the autotools I used and ran for ages now. But I receive this error: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found when compiled with gfortran47. Add -rpath /usr/local/lib/gcc47 Thanks. I'll give it a try. I'm a bit curious why gcc 4.6 is working, while gcc 4.7 isn't, since I use a autotool environment (configure.ac etc.) to build the tool. Well, I was rude in changing gcc46 to gcc47 and forgot to perform portupgrade -fo lang/gcc47 gcc-4.6.. Since pkgdb -F still doesn't work, I can not repair the dependencies automatically. I guess, or I suspect (but I do not really know) that a tool/libtool or similar is still assuming gcc 4.6. Thanks anyway, regards, Oliver signature.asc Description: OpenPGP digital signature
[head tinderbox] failure on i386/i386
TB --- 2012-11-12 08:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-12 08:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-12 08:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-12 08:50:00 - cleaning the object tree TB --- 2012-11-12 08:50:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-12 08:50:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-12 08:50:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-12 08:52:23 - /usr/local/bin/svn update /src TB --- 2012-11-12 08:52:36 - At svn revision 242910 TB --- 2012-11-12 08:52:37 - building world TB --- 2012-11-12 08:52:37 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 08:52:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 08:52:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 08:52:37 - SRCCONF=/dev/null TB --- 2012-11-12 08:52:37 - TARGET=i386 TB --- 2012-11-12 08:52:37 - TARGET_ARCH=i386 TB --- 2012-11-12 08:52:37 - TZ=UTC TB --- 2012-11-12 08:52:37 - __MAKE_CONF=/dev/null TB --- 2012-11-12 08:52:37 - cd /src TB --- 2012-11-12 08:52:37 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Nov 12 08:52:44 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Nov 12 11:54:48 UTC 2012 TB --- 2012-11-12 11:54:48 - generating LINT kernel config TB --- 2012-11-12 11:54:48 - cd /src/sys/i386/conf TB --- 2012-11-12 11:54:48 - /usr/bin/make -B LINT TB --- 2012-11-12 11:54:48 - cd /src/sys/i386/conf TB --- 2012-11-12 11:54:48 - /usr/sbin/config -m LINT TB --- 2012-11-12 11:54:48 - building LINT kernel TB --- 2012-11-12 11:54:48 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 11:54:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 11:54:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 11:54:48 - SRCCONF=/dev/null TB --- 2012-11-12 11:54:48 - TARGET=i386 TB --- 2012-11-12 11:54:48 - TARGET_ARCH=i386 TB --- 2012-11-12 11:54:48 - TZ=UTC TB --- 2012-11-12 11:54:48 - __MAKE_CONF=/dev/null TB --- 2012-11-12 11:54:48 - cd /src TB --- 2012-11-12 11:54:48 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Nov 12 11:54:49 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Mon Nov 12 12:26:43 UTC 2012 TB --- 2012-11-12 12:26:43 - cd /src/sys/i386/conf TB --- 2012-11-12 12:26:43 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-12 12:26:43 - building LINT-NOINET kernel TB --- 2012-11-12 12:26:43 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 12:26:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 12:26:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 12:26:43 - SRCCONF=/dev/null TB --- 2012-11-12 12:26:43 - TARGET=i386 TB --- 2012-11-12 12:26:43 - TARGET_ARCH=i386 TB --- 2012-11-12 12:26:43 - TZ=UTC TB --- 2012-11-12 12:26:43 - __MAKE_CONF=/dev/null TB --- 2012-11-12 12:26:43 - cd /src TB --- 2012-11-12 12:26:43 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Mon Nov 12 12:26:43 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Mon Nov 12 12:54:06 UTC 2012 TB --- 2012-11-12 12:54:06 - cd /src/sys/i386/conf TB --- 2012-11-12 12:54:06 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-12 12:54:06 - building LINT-NOINET6 kernel TB --- 2012-11-12 12:54:06 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 12:54:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 12:54:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 12:54:06 - SRCCONF=/dev/null TB --- 2012-11-12 12:54:06 - TARGET=i386 TB --- 2012-11-12 12:54:06 - TARGET_ARCH=i386 TB --- 2012-11-12 12:54:06 - TZ=UTC TB --- 2012-11-12 12:54:06 - __MAKE_CONF=/dev/null TB --- 2012-11-12 12:54:06 - cd /src TB --- 2012-11-12 12:54:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Mon Nov 12 12:54:07 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Mon Nov 12 13:20:17 UTC 2012 TB --- 2012-11-12 13:20:17 - cd /src/sys/i386/conf TB ---
Re: HEADS UP: Forth Optimizations
On Nov 11, 2012, at 5:30 PM, Peter Jeremy wrote:
On 2012-Nov-10 16:53:10 -0800, Devin Teske devin.te...@fisglobal.com wrote:
Can someone help review this for the commit log?
I've had a look through the proposed patch and my comments follow.
Other than that, it looks good to me.
Thanks Peter!
Replies inline below.
Index: menu-commands.4th
===
--- menu-commands.4th(revision 242835)
+++ menu-commands.4th(working copy)
...
@@ -185,21 +240,21 @@ variable root_state
...
s set kernel=${kernel_prefix}${kernel[N]}${kernel_suffix}
- \ command to assemble full kernel-path
--rot tuck 36 + c! swap\ replace 'N' with array index value
-evaluate \ sets $kernel to full kernel-path
+36 +c! \ replace 'N' with ASCII numeral
+evaluate
I think the sets $kernel to full kernel-path comment is worth keeping.
Updated, thx.
s set root=${root_prefix}${root[N]}${root_suffix}
- \ command to assemble root image-path
--rot tuck 30 + c! swap\ replace 'N' with array index value
-evaluate \ sets $kernel to full kernel-path
+30 +c! \ replace 'N' with ASCII numeral
+evaluate
Likewise, this could do with a (corrected) comment that it sets $root
to the full path to root.
Likewise, updated.
Index: menu.4th
===
--- menu.4th (revision 242835)
+++ menu.4th (working copy)
@@ -184,18 +223,15 @@ create init_text8 255 allot
\ base name of environment variable
loader_color? if
-s ansi_caption[x]
+dup ansi_caption[x]
else
-s menu_caption[x]
+dup menu_caption[x]
then
Could this be simplified to
= dup
= loader_color? if
= ansi_caption[x]
= else
= menu_caption[x]
= then
Sure, done. Actually, found two occurrences of this that I corrected.
Or, at a higher level, should this whole block be pulled into a new
word (along with similar words for toggled_{ansi,text}[x] and
{ansi,menu}_caption[x][y]?
I looked at the uses where ansi* is used in place of non-ansi* and it's not
just within loader_color? blocks (that was in-fact the minority of cases).
Cooking it down further would make things more complicated I fear.
If I come up with a cute way to simplify this, I'll try it out in another
commit.
@@ -227,36 +263,26 @@ create init_text8 255 allot
...
getenv dup -1 if
\ Assign toggled text to menu caption
Some comments on stack contents around here would make it somewhat
easier to follow what is going on.
Done. I also made updates to cycle_menuitem for similarly-dense code.
@@ -329,19 +340,18 @@ create init_text8 255 allot
...
\ This is highly unlikely to occur, but to make
\ sure that things move along smoothly, allocate
\ a temporary NULL string
+drop ( getenv cruft )
s
then
then
Is this the memory leak? If so, can I suggest that this be commited
separately since it is a simple change and is distinct from the other
changes you are proposing.
You got it. Committed as r242923
@@ -357,14 +367,14 @@ create init_text8 255 allot
\
\ Let's perform what we need to with the above.
-\ base name of menuitem caption var
+\ Assign array value text to menu caption
+4 pick
According to the docementation just above this hunk, there are only 4
items on the stack, so 4 pick seems wrong, though it is consistent
with my understanding of the old code. The 2 pick [char] 0 you
added earlier seems to similarly be out-by-one, though consistent.
My mistake was that the comments need to be updated to say C-Addr/U not C-Addr
(the C-Addr/U counts to make 5 items on the stack, satisfying the 4 pick).
I've updated the comment to reflect the stack contents more accurately.
@@ -521,17 +528,20 @@ create init_text8 255 allot
\ If this is the ACPI menu option, act accordingly.
dup menuacpi @ = if
-acpimenuitem ( -- C-Addr/U | -1 )
+dup acpimenuitem ( n -- n n c-addr/u | n n -1 )
+dup -1 if
+13 +c! ( n n c-addr/u -- n ) \ replace 'x'
I think the stack here should be ( n n c-addr/u -- n c-addr/u )
Good catch! Updated.
@@ -950,100 +914,43 @@ create init_text8 255 allot
49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8')
begin
-\ Unset variables in-order of appearance in menu.4th(8)
Does the order matter?
USB keyboard problem
hello, I believe my keyboard is being detected as a mouse by mistake using amd64 HEAD svn r242748 I can not use this keyboard, I have to plug in another one. this is also broken in FreeBSD 9.1RC3 is this simple to patch? any help is appreciated uhid0: Razer Razer BlackWidow, class 0/0, rev 2.00/2.00, addr 1 on usbus0 uhid1: vendor 0x04d9 product 0x1203, class 0/0, rev 2.00/2.80, addr 2 on usbus3 ums0: Razer Razer BlackWidow, class 0/0, rev 2.00/2.00, addr 1 on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ums1: Razer Razer Naga, class 0/0, rev 2.00/2.00, addr 2 on usbus0 ums1: 7 buttons and [XYZ] coordinates ID=0 verbose dmesg follows http://www.samjess.com/keyboard.txt -- 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
can't open '/boot/menusets.4th'
Hello, Today I booted r242670 from the console and noticed this error message: can't open '/boot/menusets.4th': no such file of directory Error while including /boot/menu-commands.4th, in the line include /boot/menusets.4th Error while including /boot/menu.rc, in the line include /boot/menu-commands.4th Anyone seen this before? Darrel ___ 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: can't open '/boot/menusets.4th'
On Mon, Nov 12, 2012 at 06:11:43PM -0500, Darrel wrote: Hello, Today I booted r242670 from the console and noticed this error message: can't open '/boot/menusets.4th': no such file of directory Error while including /boot/menu-commands.4th, in the line include /boot/menusets.4th Error while including /boot/menu.rc, in the line include /boot/menu-commands.4th Seems to be fixed by r242688. -- Mateusz Guzik mjguzik gmail.com ___ 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: can't open '/boot/menusets.4th'
On Mon, Nov 12, 2012 at 06:11:43PM -0500, Darrel wrote: Hello, Today I booted r242670 from the console and noticed this error message: can't open '/boot/menusets.4th': no such file of directory Error while including /boot/menu-commands.4th, in the line include /boot/menusets.4th Error while including /boot/menu.rc, in the line include /boot/menu-commands.4th Anyone seen this before? Yes. This is fixed a few hours after it was introduced. Glen pgpeoE511AlyM.pgp Description: PGP signature
Too many dynamic rules
Hello, Today I booted r242670 from the console and noticed an error. This is one line from the end of dmesg: ipfw: ipfw_install_state: Too many dynamic rules The ruleset has always been dynamic and has no additional rules. Search engines produced similar error messages, but no information that seems to be the correct solution. I have a basically identical ruleset on fbsd91 and no error message. Any ideas? Darrel ___ 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
[head tinderbox] failure on i386/i386
TB --- 2012-11-12 18:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-12 18:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-12 18:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-12 18:40:00 - cleaning the object tree TB --- 2012-11-12 18:48:32 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-12 18:48:32 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-12 18:48:32 - /usr/local/bin/svn cleanup /src TB --- 2012-11-12 18:50:36 - /usr/local/bin/svn update /src TB --- 2012-11-12 18:50:43 - At svn revision 242923 TB --- 2012-11-12 18:50:44 - building world TB --- 2012-11-12 18:50:44 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 18:50:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 18:50:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 18:50:44 - SRCCONF=/dev/null TB --- 2012-11-12 18:50:44 - TARGET=i386 TB --- 2012-11-12 18:50:44 - TARGET_ARCH=i386 TB --- 2012-11-12 18:50:44 - TZ=UTC TB --- 2012-11-12 18:50:44 - __MAKE_CONF=/dev/null TB --- 2012-11-12 18:50:44 - cd /src TB --- 2012-11-12 18:50:44 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Nov 12 18:50:50 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Nov 12 21:46:44 UTC 2012 TB --- 2012-11-12 21:46:44 - generating LINT kernel config TB --- 2012-11-12 21:46:44 - cd /src/sys/i386/conf TB --- 2012-11-12 21:46:44 - /usr/bin/make -B LINT TB --- 2012-11-12 21:46:44 - cd /src/sys/i386/conf TB --- 2012-11-12 21:46:44 - /usr/sbin/config -m LINT TB --- 2012-11-12 21:46:44 - building LINT kernel TB --- 2012-11-12 21:46:44 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 21:46:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 21:46:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 21:46:44 - SRCCONF=/dev/null TB --- 2012-11-12 21:46:44 - TARGET=i386 TB --- 2012-11-12 21:46:44 - TARGET_ARCH=i386 TB --- 2012-11-12 21:46:44 - TZ=UTC TB --- 2012-11-12 21:46:44 - __MAKE_CONF=/dev/null TB --- 2012-11-12 21:46:44 - cd /src TB --- 2012-11-12 21:46:44 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Nov 12 21:46:45 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Mon Nov 12 22:17:00 UTC 2012 TB --- 2012-11-12 22:17:00 - cd /src/sys/i386/conf TB --- 2012-11-12 22:17:00 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-12 22:17:00 - building LINT-NOINET kernel TB --- 2012-11-12 22:17:00 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 22:17:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 22:17:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 22:17:00 - SRCCONF=/dev/null TB --- 2012-11-12 22:17:00 - TARGET=i386 TB --- 2012-11-12 22:17:00 - TARGET_ARCH=i386 TB --- 2012-11-12 22:17:00 - TZ=UTC TB --- 2012-11-12 22:17:00 - __MAKE_CONF=/dev/null TB --- 2012-11-12 22:17:00 - cd /src TB --- 2012-11-12 22:17:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Mon Nov 12 22:17:00 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Mon Nov 12 22:43:53 UTC 2012 TB --- 2012-11-12 22:43:53 - cd /src/sys/i386/conf TB --- 2012-11-12 22:43:53 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-12 22:43:53 - building LINT-NOINET6 kernel TB --- 2012-11-12 22:43:53 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 22:43:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 22:43:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 22:43:53 - SRCCONF=/dev/null TB --- 2012-11-12 22:43:53 - TARGET=i386 TB --- 2012-11-12 22:43:53 - TARGET_ARCH=i386 TB --- 2012-11-12 22:43:53 - TZ=UTC TB --- 2012-11-12 22:43:53 - __MAKE_CONF=/dev/null TB --- 2012-11-12 22:43:53 - cd /src TB --- 2012-11-12 22:43:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Mon Nov 12 22:43:53 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Mon Nov 12 23:11:26 UTC 2012 TB --- 2012-11-12 23:11:26 - cd /src/sys/i386/conf TB ---
Re: Too many dynamic rules
In the last episode (Nov 12), Darrel said: Hello, Today I booted r242670 from the console and noticed an error. This is one line from the end of dmesg: ipfw: ipfw_install_state: Too many dynamic rules The ruleset has always been dynamic and has no additional rules. Search engines produced similar error messages, but no information that seems to be the correct solution. I have a basically identical ruleset on fbsd91 and no error message. That means that the dynamic rules generated by the keep-state keyword hit the currently-confgured limit. If you get hit with a lot of random traffic that matches a keep-state rule, you'll get that message. It's not the rules themselves that cause this, it's the traffic. Run sysctl net.inet.ip.fw.dyn_max net.inet.ip.fw.dyn_count and compare the two values. If count is near to dyn_max, you can simply raise dyn_max. It's a writeable sysctl. I set it to 65535 on my systems in /etc/sysctl.conf with no apparent ill effects. -- Dan Nelson dnel...@allantgroup.com ___ 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
