Date: Sun, 04 May 2003 12:36:16 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt <matt@xtaz.co.uk> Cc: current@freebsd.org Subject: Re: m_freem detected a mbuf double-free : xl0 kernel panic Message-ID: <3EB56BB0.32DC4347@mindspring.com> References: <49952.192.168.1.10.1052046537.squirrel@webmail.xtaz.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt wrote: > Unfortunatly this machine does not have enough swap space to dump a panic > and I also do not have a serial console so there is no debug information, > but I am getting a 100% reproducable panic on a kernel built on sources > cvsup'd either an hour ago or yesterday morning (I've tried both). Sources > from friday are fine. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options DDB #Enable the kernel debugger > The important looking parts I scribbled down on some paper from ddb are > m_freem detected a mbuf double-free, kernel trap 12 with interrupts > disabled, current process int12: xl0. > > This happens the second my irc client tries to connect to an irc server > after booting the system. If I boot kernel.old (from friday) it works > fine. > > Hopefully somebody else with a nic using the xl driver has the same > problem and could offer some proper debug. If not I will try and add more > swap space so I can get a core file. Look elsewhere; the if_xl.c/if_xlreg.h hasn't been modified for over 13 days, so it's not an if_xl.c specific problem that came in last Friday. Probably you had not updated for a while (if it's really an if_xl problem -- and you need to tell us how old your tree was), or it's a problem that was introduced elsewhere, and happened to bite you in the if_xl.c code. I expect that this is the case. You should look for changed files. Actually, I think it's rev 1.47 of /src/sys/kern/subr_mbuf.c; I don't actually see where the M_FREELIST flag is ever cleared on allocation... might want to send an email to silby@. Alternately, if it is cleared on allocation somewhere I'm not seeing, it may be a revealed by in the if_xl driver... or some place else in the protocol stack, where it's freeing the mbuf, and then continuing to use it. I remember a case in the ipfw code, at one point, where it would do that on "reject" rules, and then corrupt the heck out of the kernel stack. 8-(. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB56BB0.32DC4347>