Date: Wed, 7 Feb 2001 14:28:53 +0800 From: Yusuf Goolamabbas <yusufg@outblaze.com> To: Joao Carlos Mendes Luis <jonny@jonny.eng.br> Cc: Luigi Rizzo <rizzo@aciri.org>, freebsd-net@FreeBSD.ORG, freebsd-stable@freebsd.org, phk@freebsd.org, dwmalone@FreeBSD.org Subject: Re: Solved: Bridging and dummynet seems to destroy dmesg output Message-ID: <20010207142853.A30058@outblaze.com> In-Reply-To: <3A79B707.3DF0B6D@jonny.eng.br>; from jonny@jonny.eng.br on Thu, Feb 01, 2001 at 05:20:39PM -0200 References: <200101312212.f0VMCHj08290@iguana.aciri.org> <3A79B707.3DF0B6D@jonny.eng.br>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I cvsupped today and got all of Luigi's commit [the one where he does 1.16.2.13 of bridge.c alongwith a few others], I also have David Malone's fix to syslogd.c [1.59.2.5] If I don't have the following sysctl net.inet.ip.fw.verbose_limit=10 then dmesg gets busted as mentioned earlier and if I do a sync;reboot then I get a huge amount of ipfw messages scrolling on the console [It's as if they were backlogged in some buffer somewhere] and after a few seconds the syncing disk messages comes along I have the following in my kernel config options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options BRIDGE options DUMMYNET my /etc/sysctl.conf is as follows net.link.ether.bridge_ipfw=1 net.link.ether.bridge=1 net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=10 > Luigi Rizzo wrote: > > > > > I tried only removing DUMMYNET from config, and the bug continues. Should > > > I try the changes below? > > > > no-they only affect dummynet. But this seems to suggest that > > the problem is unrelated to my changes... > > > > cheers > > luigi > > Hi, > > I found the problem! > > I started searching for the point where ipfw writes to the msgbuf, and > like all other kernel modules, it uses the log(9) function. But differently > from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it, > recompiled, reboot, and BINGO! Probably the log(9) function does not expect a > facility parameter, as it is assumed to be LOG_KERNEL. > > Searching the cvsweb tree, I assume the changes that made it fail were > made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a > longer search should be made to detect if any other call to log(9) uses this > approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at > 2000.01.16) > > Hoping this is the final solution and waiting for the cvs commit, thanks > to everybody, > > Jonny > > -- > João Carlos Mendes Luís jonny@embratel.net.br > Networking Engineer jonny@jonny.eng.br > Internet via Embratel jcml@ieee.org -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010207142853.A30058>