sctp panic: Huh, its non zero and nothing on control?
Randall Stewart
rrs at cisco.com
Tue Sep 18 08:11:16 PDT 2007
Mark:
How old of version are you running? One of these type of
panic's was removed a bit ago.. but there is still one
case that will panic like this...
And you should be able to run invariants and have it run
(although a lot slower of course)...
If your current to within say the end of the SCTP interop
(which would have been the end of Aug) then lets speak
offline and let me see if I can get a core from you and
the kernel...etc.. this is one I would like to look at.
If its quite old.. then can you sup and rerun?
The case this flags can be repaired .. but it should NOT
happen.. at least in theory.. if its the one occurance
of this thats left.
I am running on an 8 core machine (AMD64) and don't see
this.. but thats not to say its not a problem :-)
Let me know
Thanks
R
Mark Atkinson wrote:
> I got this panic today while testing sctp on a different target with this
> box as a client, although the version of current is a little crusty (maybe
> I should be running sctp without INVARIANTS?)
>
> FreeBSD 7.0-CURRENT #1: Fri Aug 10 08:14:46 PDT 2007
>
> panic: Huh, its non zero and nothing on control?
> cpuid = 1
> KDB: enter: panic
> [thread pid 8815 tid 100130 ]
> Stopped at kdb_enter+0x32: leave
> db>
> db> where
> Tracing pid 8815 tid 100130 td 0xc5992000
> kdb_enter(c0aa11be,1,c0ab6a33,e83e8930,1,...) at kdb_enter+0x32
> panic(c0ab6a33,0,c0ab68a2,130b,c70c3b48,...) at panic+0x124
> sctp_sorecvmsg(c70c3ad4,e83e8bf4,0,e83e8a8c,100,...) at sctp_sorecvmsg+0x3e4
> sctp_soreceive(c70c3ad4,e83e8be8,e83e8bf4,0,0,...) at sctp_soreceive+0x9e
> soreceive(c70c3ad4,e83e8be8,e83e8bf4,0,0,...) at soreceive+0x4d
> kern_recvit(c5992000,3,e83e8c60,0,0,...) at kern_recvit+0x153
> recvit(0,c0aa2cd4,83b,bfbcdec8,3e8,0,0,e83e8c58,1,0,281aceb8,0) at
> recvit+0x31
> recvfrom(c5992000,e83e8cfc,18,c0aa6ebd,c0b4ec18,...) at recvfrom+0x76
> syscall(e83e8d38) at syscall+0x2b3
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x281558e7, esp =
> 0xbfbcddfc, ebp = 0xbfbcde28 ---
> db> call doadump
> Physical memory: 2034 MB
> Dumping 278 MB: 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7
> Dump complete
> = 0xf
>
>
> [root at marka-k8we K8WE]$ kgdb kernel.debug /var/crash/vmcore.1
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
> panic: Huh, its non zero and nothing on control?
> cpuid = 1
> KDB: enter: panic
> Physical memory: 2034 MB
> Dumping 278 MB: 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7
>
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0 doadump () at pcpu.h:195
> #1 0xc048cbc9 in db_fncall (dummy1=-1065925454, dummy2=0, dummy3=-1,
> dummy4=0xe83e8708 "") at /usr/src/sys/ddb/db_command.c:486
> #2 0xc048d135 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401
> #3 0xc048e8b5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222
> #4 0xc0774335 in kdb_trap (type=3, code=0, tf=0xe83e88b0)
> at /usr/src/sys/kern/subr_kdb.c:502
> #5 0xc0a0a88f in trap (frame=0xe83e88b0)
> at /usr/src/sys/i386/i386/trap.c:621
> #6 0xc09f0edb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #7 0xc07744b2 in kdb_enter (msg=0xc0aa11be "panic") at cpufunc.h:60
> #8 0xc074bb54 in panic (
> fmt=0xc0ab6a33 "Huh, its non zero and nothing on control?")
> at /usr/src/sys/kern/kern_shutdown.c:547
> #9 0xc0880114 in sctp_sorecvmsg (so=0xc70c3ad4, uio=0xe83e8bf4, mp=0x0,
> from=0xe83e8a8c, fromlen=256, msg_flags=0xe83e8c78, sinfo=0xe83e8a0c,
> filling_sinfo=0) at /usr/src/sys/netinet/sctputil.c:4881
> #10 0xc088186e in sctp_soreceive (so=0xc70c3ad4, psa=0xe83e8be8,
> uio=0xe83e8bf4, mp0=0x0, controlp=0x0, flagsp=0xe83e8c78)
> at /usr/src/sys/netinet/sctputil.c:5687
> #11 0xc07a240d in soreceive (so=0xc70c3ad4, psa=0xe83e8be8, uio=0xe83e8bf4,
> mp0=0x0, controlp=0x0, flagsp=0xe83e8c78)
> at /usr/src/sys/kern/uipc_socket.c:1853
> #12 0xc07a8763 in kern_recvit (td=0xc5992000, s=3, mp=0xe83e8c60,
> ---Type <return> to continue, or q <return> to quit---
> fromseg=UIO_USERSPACE, controlp=0x0)
> at /usr/src/sys/kern/uipc_syscalls.c:986
> #13 0xc07a8951 in recvit (td=Variable "td" is not available.
> ) at /usr/src/sys/kern/uipc_syscalls.c:1093
> #14 0xc07a8ac6 in recvfrom (td=0xc5992000, uap=0xe83e8cfc)
> at /usr/src/sys/kern/uipc_syscalls.c:1137
> #15 0xc0a0a063 in syscall (frame=0xe83e8d38)
> at /usr/src/sys/i386/i386/trap.c:1008
> #16 0xc09f0f40 in Xint0x80_syscall ()
> at /usr/src/sys/i386/i386/exception.s:196
> #17 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
> (kgdb) frame 9
> #9 0xc0880114 in sctp_sorecvmsg (so=0xc70c3ad4, uio=0xe83e8bf4, mp=0x0,
> from=0xe83e8a8c, fromlen=256, msg_flags=0xe83e8c78, sinfo=0xe83e8a0c,
> filling_sinfo=0) at /usr/src/sys/netinet/sctputil.c:4881
> 4881 panic("Huh, its non zero and nothing on
> control?");
> (kgdb) list
> 4876 hold_rlock = 1;
> 4877 }
> 4878 control = TAILQ_FIRST(&inp->read_queue);
> 4879 if ((control == NULL) && (so->so_rcv.sb_cc != 0)) {
> 4880 #ifdef INVARIANTS
> 4881 panic("Huh, its non zero and nothing on
> control?");
> 4882 #endif
> 4883 so->so_rcv.sb_cc = 0;
> 4884 }
> 4885 SCTP_INP_READ_UNLOCK(inp);
> (kgdb)
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
More information about the freebsd-current
mailing list