Date: Fri, 24 May 2002 15:08:04 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Archie Cobbs <archie@dellroad.org>, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: splimp() during panic? Message-ID: <200205242208.g4OM84v71088@arch20m.dellroad.org> In-Reply-To: <20020524155207.A25775@unixdaemons.com> "from Bosko Milekic at May 24, 2002 03:52:07 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic writes: > > My question is: does this guarantee that the mbuf free lists, etc. will > > not be modified between the time panic() is called and the time a core > > file is generated? For example, if an incoming packet causes a networking > > interrupt after panic() has been called but before the core file is > > written, will that interrupt be blocked when it calls splimp()? > > splimp() ensures that no driver handlers will be executed. Further, > dumpsys() is called from panic() at splhigh() which would also mean > that none of those potentially troublesome handlers will run. OK, good... > > I've been working under this assumption but it seems to not be > > valid, because I seem to be seeing panics for situations that are > > not true in the core file. > > Are you seeing invalid stuff from DDB but valid stuff from the core > file? Because if so, that's REALLY WIERD. If you're just seeing two > different but invalid things, then perhaps something is happening when > Debugger() runs (is it possible that the cpl() is changed after > or before a breakpoint()?). I'm not trying to use DDB for debugging.. just letting it panic and generate the core file and then using GDB to examine it. I got one panic that happened because mclfree was NULL (it was a bug in the debug code :-) but looking at mclfree in the core file with GDB showed it to be not NULL. So somehow some mbuf operation must have occurred in there somewhere that modified mclfree it seems. > > If this is not a valid assumption, is there an easy way to 'freeze' > > the mbuf free lists long enough to generate the core file when an > > inconsistency is found (other than adding the obvious hack)? > > To make doubly-sure, what you can do is just keep a variable 'foo' > which you initialize to 0. Before any mbuf free list manipulations, > place a 'if (foo == 0)' check. Atomically set foo to 1 before the > panic. See if the inconsistency changes. If you're seeing garbage in Yep, I'll probably do that as well.. thanks. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205242208.g4OM84v71088>