Date: Sat, 28 Feb 2009 14:46:42 +0200 From: Artis Caune <artis.caune@gmail.com> To: "Michael K. Smith - Adhost" <mksmith@adhost.com> Cc: freebsd-pf@freebsd.org Subject: Re: Issues with PF and 7.1 Message-ID: <9e20d71e0902280446n4a49e693p70930dd88a349568@mail.gmail.com> In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605658786@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316056585C1@ad-exh01.adhost.lan> <d5992baf0901230921h27e78ffndfc2e20d1f7ff6eb@mail.gmail.com> <200901231904.22558.max@love2party.net> <17838240D9A5544AAA5FF95F8D52031605658786@ad-exh01.adhost.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/1/24 Michael K. Smith - Adhost <mksmith@adhost.com>: > Thanks for the info. =C2=A0In stages, we upped the vm.kmem_size_max from = 300M to 1536M after modifying the kernel (we actually tried 2048M but that = caused a panic). =C2=A0With the 1536M setting the 'DIOCADDRULE: Cannot allo= cate memory' doesn't occur anymore, but we still have to flush the tables m= anually when the system comes up. =C2=A0Now, at least, the flush actually w= orks and PF loads successfully, but only after we do the flush on all the t= ables. =C2=A0As you can imagine, this is not optimal for unattended/random = reboots, which we see about 3 times a week. You are running i386? (if you have modified the kernel) Can you try to edit i386/include/pmap.h and change NKPT to 128 and recompile the kernel. --=20 regards, Artis Caune <----. CCNA | BSDA <----|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <----' didii FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9e20d71e0902280446n4a49e693p70930dd88a349568>