Re: panic: mutex tcp owned at /usr/src/sys/netinet/tcp_input.c:2475

On Mon, May 14, 2007 at 12:17:28AM +0200, Stefan Bethke wrote:
> 
> Am 13.05.2007 um 21:45 schrieb Attilio Rao:
> 
> >2007/5/11, Stefan Bethke <stb_at_lassitu.de>:
> >>
> >>Am 11.05.2007 um 22:33 schrieb Andre Oppermann:
> >>
> >>> Stefan Bethke wrote:
> >>>> Got this reproducable panic on AMD64 on a couple of days old -
> >>>> current  when I try to copy a file off a ZFS dataset via
> >>>> netatalk's afpd (via  TCP, no actual AppleTalk involved).
> >>>
> >>> This is a recursive leak of the INP_INFO_LOCK() you've hit here.
> >>> We don't
> >>> know yet where it gets leaked but we're working on it.
> >>
> >>Hhm.  I can trigger it very easily.  I don't have a serial console on
> >>this box, but I could try a few things in a debugger if anyone wants
> >>me to look at anything in particular.
> >
> >Hello Stefan,
> >can you please recompile your kernel with INVARIANTS, DDB and KTR  
> >support?
> >
> >Just add those lines:
> >options INVARIANTS
> >options INVARIANT_SUPPORT
> >options KDB
> >options DDB
> >options KTR
> >options KTR_COMPILE=(KTR_LOCK)
> >options KTR_ENTRIES=65534
> >
> >and possibly remove kbdmux from your config file (not sure if it has
> >still problems with our syscons, though).
> >
> >Then, when you hit that panic you should just be redirected to ddb.
> >At that point please write 'show ktr' in the ddb prompt and report
> >what it shows.
> 
> Left kbdmux in for the moment. Hit the panic, and show ktr shows  
> nothings:
> 
> db> show ktr
> --- End of trace buffer ---
> db>
> 
> If you think it's useful, I can remove kdbmux as well and try again.

You also need KTR_MASK=(KTR_LOCK) (or set debug.ktr.mask at runtime),
this filters the events that are logged.

Kris