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:
>
> > Started running with debug.mpsafe=1.  Not shure if it has anything to do
> > with it....
>
> It might well do, but here are some things to try:
>
> - See if you can reproduce this with your exact some configuration in a
>   few runs.  If you can, then we should try some other configurations.

Yup, just got almost the same one....
It took a little longer, but perhaps cause I did not untar the port I'm trying
to test on amd64.

Slab at 0xffffff006624ffa0, freei 29 = 0.
panic: Duplicate free of item 0xffffff006624fcb0 from zone 0xffffff007fed4180(Fi
les)

cpuid = 1;
KDB: stack backtrace:
kdb_backtrace() at kdb_backtrace+0x34
panic() at panic+0x1d2
uma_dbg_free() at uma_dbg_free+0x112
uma_zfree_arg() at uma_zfree_arg+0x10a
ffree() at ffree+0x8e
fdrop_locked() at fdrop_locked+0xce
fdrop() at fdrop+0x32
getdirentries() at getdirentries+0x2fc
syscall() at syscall+0x2fa
Xfast_syscall() at Xfast_syscall+0xa8
--- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x2006a2204, rsp = 0x7fff
ffffe758, rbp = 0x7fffffffe780 ---
KDB: enter: panic
[thread 100132]
Stopped at      kdb_enter+0x2e: nop

I'll try one more time.

> - Try it with debug.mpsafenet=0 and see if the problem "goes away" for a
>   few runs.

I'll disable mpsafenet for the then next 2 runs...

> - 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?

For future steps.

> I'll do some review of the TCP reassembly and queue bits, it could well be
> that we're missing some locking here.  Nicely configured system, btw. :-)

I needed a "big" tax/profit reduction in my company....
Why not spend it on a nice toy.

> BTW, I noticed that there are some bge0 warnings at the end of the dmesg
> -- is that indicative of some other problem with the driver on the system,
> and/or is bge0 used in your active configuration?  Thanks for the nice
> bundling of config information, btw -- it answered a number of my
> questions up front quite nicely.

Thanx, I think that is the simpelest way for me to keep this easy available.
I'm considering updating this info with a /usr/local/etc/rc.d script...
Just timestamp it, and autoremove things older than a few versions.

The bge0 device is the active one.... It plugs into a noname switch, and it
could be that line-negotiation is not fast enough to be ready for the bge0 to
timeout on handshaking to get the line-mode.
The watchdog reset gets things straightend out. Not it is a onboard Broadcom
BCM5705, which has perhaps some flaws (as was claimed some time ago???)

We're up again, but I'll remove the de0 card first.

To be continued,
--WjW