Archie Cobbs wrote: > Hi, > > I'm trying to debug a mbuf corruption bug in the kernel. I've added > an mbuf sanity check routine which calls panic() if anything is amiss > with the mbuf free list, etc. This function runs at splimp() and if/when > it calls panic() the cpl is still at splimp(). > > 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. > 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()?). > 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 both cases, but the garbage is inconsistent, perhaps there's a memory problem or the dump isn't working properly (I've never heard of anything like this before). > Thanks, > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com Regards, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
