Date: Wed, 21 Feb 2001 11:02:55 +0800 From: Yusuf Goolamabbas <yusufg@outblaze.com> To: Luigi Rizzo <rizzo@aciri.org> 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> In-Reply-To: <200102200330.f1K3UJC42482@iguana.aciri.org>; from rizzo@aciri.org on Mon, Feb 19, 2001 at 07:30:19PM -0800 References: <20010220112154.A26373@outblaze.com> <200102200330.f1K3UJC42482@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi, PHK In case you might not be on -stable Thomas Moestl <tmoestl@gmx.net> 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-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010221110255.A14313>