Re: panic: Duplicate free of item 0xffffff005c4a8600 from zone 0xffffff007fed4780(Mbuf)

From: "Robert Watson" <rwatson_at_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