Date: Sun, 18 Jul 2004 21:16:51 +0200 From: "Willem Jan Withagen" <wjw@withagen.nl> To: "Robert Watson" <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: panic: Duplicate free of item 0xffffff005c4a8600 from zone 0xffffff007fed4780(Mbuf) Message-ID: <106d01c46cfb$c7d76630$471b3dd4@digiware.nl> References: <Pine.NEB.3.96L.1040718151152.37108j-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Robert Watson" <rwatson@freebsd.org> > On Sun, 18 Jul 2004, Willem Jan Withagen wrote: > > > Starting on: > > > > > - Try compiling IPv6 out of your kernel -- this will turn on the inpcb > > > locking assertions, which are compiled out by default because IPv4 and > > > IPv6 share the same underlying pcb code and IPv6 does not yet lock that > > > correctly in CVS. I have patches that do quite a bit of that in > > > Perforce, and sent out an e-mail yesterday to the KAME folk to talk > > > about merging strategies. > > > > > > - If this is a reproduceable problem, could you try disabling SACK and see > > > if it changes at all? > > > > How do I disable SACK?? Probably there's a flag for, but which.... > > The sysctl net.inet.tcp.sack.enable enables (and disables) SACK. Given > some of the other versions of the trace you're reporting, it's seeming > less like it's SACK that's causing the problem, but it's definitely worth > trying. We could be looking at an issue with the bge driver -- I have > some bge cards and will see about sticking one into a machine here for > testing. Can you suggest a workload I can try that will reliably generate > the panic for you? Well I could also try this with the em0 interface, and see if the same occurs.... What am I doing to get the panic: In one shell I try to compile /usr/ports/net-mgmt/net-snmp. (Well actually the one I'm working on to get the last tweak out of it when running amd64) And that I keep repeating until it crashes, but unusally one run is enough. In the console I run 'periodic daily', since my box currently always seems to crash during the night when running daily. In a third window I do some work: usually some vi-ing or grepping.... And you write: > > Does not seem to help.... Not shure if anything should be read in the > > fact that it is 3 times in [thread 100007]. > > Well, the threads involved seem to be the netisr thread and the bge > interrupt thread, suggesting we have a problem with mbufs being free'd > despite being handed off into the network stack. Up front, it suggests > maybe we have an issue with the bge driver freeing or reusing an mbuf > inappropriately, or perhaps it's at the TCP layer. Even more reason to do some (ab)using test with the em0 card??? --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?106d01c46cfb$c7d76630$471b3dd4>