From owner-freebsd-net Tue Feb 20 18:57:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id A7C9B37B401 for ; Tue, 20 Feb 2001 18:57:42 -0800 (PST) (envelope-from yusufg@outblaze.com) Received: (qmail 58852 invoked from network); 21 Feb 2001 02:57:39 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 21 Feb 2001 02:57:39 -0000 Received: (qmail 14337 invoked by uid 500); 21 Feb 2001 03:02:55 -0000 Date: Wed, 21 Feb 2001 11:02:55 +0800 From: Yusuf Goolamabbas To: Luigi Rizzo Cc: jonny@jonny.eng.br, 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: <20010221110255.A14313@outblaze.com> References: <20010220112154.A26373@outblaze.com> <200102200330.f1K3UJC42482@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200102200330.f1K3UJC42482@iguana.aciri.org>; from rizzo@aciri.org on Mon, Feb 19, 2001 at 07:30:19PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi, PHK In case you might not be on -stable Thomas Moestl just wrote a mesg to -stable trying to explain "dmesg flakyness". cut/paste from his message Have you tried "dmesg -a"? It seems like the above message is from syslog (if something is printed on into /dev/console, this is also recorded in the message buffer). dmesg by default ignores messages that are not from the kernel, but it cannot determine this if the first characters of a line are missing. The missing characters get lost when the oldest messages are partly overwritten by new ones (the message buffer is a ring buffer). > > Luigi, PHK > > > > Any resolution on this ? > > for sure there is no bug in ip_fw.c -- the change mentioned below just > happens to change some symptoms but is no fix. > > The message buffer is not "busted" as the report says, just has > some NULs here and there that (probably) dmesg is not handling > correctly. Poul, do you know more ? > > cheers > luigi > > > > Regards, Yusuf > > > > > Hi Yusuf, > > > > > > As described by cvsweb, the patches to IPFW did not change the behavior > > > with log messages. To be more exactly, either netinet/ip_fw.c either > > > kern/subr_prf.c should be changed to match each other. In my local setup I > > > use a patch script after cvsup to fix ip_fw.c, removing all instances of > > > "LOG_SECURITY |". > > > > > > Luigi/Poul, have you at least decided where the changes should be made? > > > There's no log(9) man page to decide which one is the correct syntax. IMHO, > > > -stable is not stable while this bug persists. > > > > > > Yusuf Goolamabbas wrote: > > > > > > > > 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 > > > > > > -- > > > > > > 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 > > > -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message