On Sat, 24 Nov 2007, Rako wrote: > the patch solve the problem with tcpdrop, Thanks!! > > An other panic ocurred, but on other area, is on snp.ko module (watch -W > /dev/ttyv0) but can't get backtrace. This panic is simliar at > > http://lists.freebsd.org/pipermail/freebsd-current/2007-March/069990.html > > the problem may be at line 164 of /usr/src/sys/dev/snp/snp.c snp = > ttytosnp(tp); > > where snp get NULL > > but, no familiar with this ... Any idea what can I do to solve the error? I'm having trouble reproducing this -- could you give me a detailed set of instructions regarding the specific steps I should take to try and get this panic, if it's reproduceable for you? Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > Regards, > Javier > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x24 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc3e4f230 > stack pointer = 0x28:0xd66c3b34 > frame pointer = 0x28:0xd66c3b88 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2216 (make) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c0a5f1ea,d66c39d4,c078878a,c0a5d5f4,c0b5bcc0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c0a5d5f4,c0b5bcc0,c0a1fb8c,d66c39e0,d66c39e0,...) at > kdb_backtrace+0x29 > panic(c0a1fb8c,c0a7c54d,c3e44770,1,1,...) at panic+0xaa > trap_fatal(c3e942b8,0,1,0,c39f5630,...) at trap_fatal+0x303 > trap_pfault(0,c39f5630,c39f5630,0,c,...) at trap_pfault+0x250 > trap(d66c3af4) at trap+0x382 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc3e4f230, esp = 0xd66c3b34, ebp = 0xd66c3b88 --- > snplwrite(c33bf800,d66c3c60,0,d66c3bbc,c0754bec,...) at snplwrite+0x80 > ttywrite(c3389600,d66c3c60,0,c39cf5e8,c39f5630,...) at ttywrite+0x39 > giant_write(c3389600,d66c3c60,0,0,c0abb080,...) at giant_write+0x6c > devfs_write_f(c39cf5e8,d66c3c60,c3de4800,0,c39f5630,...) at > devfs_write_f+0x75 > dofilewrite(d66c3c60,ffffffff,ffffffff,0,c39cf5e8,...) at dofilewrite+0x97 > kern_writev(c39f5630,1,d66c3c60,2813c076,0,...) at kern_writev+0x58 > write(c39f5630,d66c3cfc,c,110,c337e630,...) at write+0x4f > syscall(d66c3d38) at syscall+0x335 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (4, FreeBSD ELF32, write), eip = 0x8083603, esp = 0xbfbfd4ec, ebp > = 0xbfbfd528 --- > Uptime: 19m14s > Physical memory: 495 MB > Dumping 86 MB: 71 55 39 23 7 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0788594 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc07887bf in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc09ccb43 in trap_fatal (frame=0xd66c3af4, eva=36) at > /usr/src/sys/i386/i386/trap.c:872 > #4 0xc09ccda0 in trap_pfault (frame=0xd66c3af4, usermode=0, eva=36) at > /usr/src/sys/i386/i386/trap.c:785 > #5 0xc09cd752 in trap (frame=0xd66c3af4) at > /usr/src/sys/i386/i386/trap.c:463 > #6 0xc09b68fb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc3e4f230 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > >> >> On Fri, 23 Nov 2007, Rako wrote: >> >>> Sorry for not send this before. >>> >>> The connection that i kill was in TIME_WAIT or FIN_WAIT_? state >>> >>> Any other information, please, tell me. >>> Javier >> >> Javier, >> >> Indeed, it looks like sysctl_drop is not handling certain TCP states >> properly with respect to locking. This is probably my fault, as it looks >> like perhaps this was fallout from the socket<->inpcb reference cleanup >> work in 7.x. The attached patch may help, could you give it a try? >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >> >>> >>> (kgdb) bt >>> #0 doadump () at pcpu.h:195 >>> #1 0xc0788594 in boot (howto=260) at >>> /usr/src/sys/kern/kern_shutdown.c:409 >>> #2 0xc07887bf in panic (fmt=Variable "fmt" is not available. >>> ) at /usr/src/sys/kern/kern_shutdown.c:563 >>> #3 0xc09ccb43 in trap_fatal (frame=0xd66589c0, eva=24) at >>> /usr/src/sys/i386/i386/trap.c:872 >>> #4 0xc09cd4dd in trap (frame=0xd66589c0) at >>> /usr/src/sys/i386/i386/trap.c:277 >>> #5 0xc09b68fb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>> #6 0xc07b8644 in turnstile_broadcast (ts=0x0, queue=0) at >>> /usr/src/sys/kern/subr_turnstile.c:834 >>> #7 0xc077ba02 in _mtx_unlock_sleep (m=0xc4c35288, opts=0, file=0x0, >>> line=0) at /usr/src/sys/kern/kern_mutex.c:593 >>> #8 0xc086ba27 in sysctl_drop (oidp=0xc0b0d2e0, arg1=0x0, arg2=0, >>> req=0xd6658ba4) at /usr/src/sys/netinet/tcp_subr.c:2057 >>> #9 0xc0791a87 in sysctl_root (oidp=Variable "oidp" is not available. >>> ) at /usr/src/sys/kern/kern_sysctl.c:1306 >>> #10 0xc0791bd4 in userland_sysctl (td=0xc38c0210, name=0xd6658c14, >>> namelen=4, old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfeb90, newlen=256, >>> retval=0xd6658c10, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1401 >>> #11 0xc07928fd in __sysctl (td=0xc38c0210, uap=0xd6658cfc) at >>> /usr/src/sys/kern/kern_sysctl.c:1336 >>> #12 0xc09cd0f5 in syscall (frame=0xd6658d38) at >>> /usr/src/sys/i386/i386/trap.c:1008 >>> #13 0xc09b6960 in Xint0x80_syscall () at >>> /usr/src/sys/i386/i386/exception.s:196 >>> #14 0x00000033 in ?? () >>> Previous frame inner to this frame (corrupt stack?) >>> >>> (kgdb) f 8 >>> #8 0xc086ba27 in sysctl_drop (oidp=0xc0b0d2e0, arg1=0x0, arg2=0, >>> req=0xd6658ba4) at /usr/src/sys/netinet/tcp_subr.c:2057 >>> 2057 INP_UNLOCK(inp); >>> (kgdb) l >>> 2052 } else if (!(inp->inp_vflag & INP_DROPPED) && >>> 2053 !(inp->inp_socket->so_options & >>> SO_ACCEPTCONN)) { >>> 2054 tp = intotcpcb(inp); >>> 2055 tcp_drop(tp, ECONNABORTED); >>> 2056 } >>> 2057 INP_UNLOCK(inp); >>> 2058 } else >>> 2059 error = ESRCH; >>> 2060 INP_INFO_WUNLOCK(&tcbinfo); >>> 2061 return (error); >>> (kgdb) >>> >>>> >>>> On Fri, 23 Nov 2007, Javier wrote: >>>> >>>>> Hi, a got a panic with tcpdrop command. >>>> >>>> Javier, >>>> >>>> I see you may have a coredump -- could you provide a backtrace from gdb >>>> for the below? Specifically, I'd like to know what line >>>> sysctl_drop+0x207 is. >>>> >>>> Thanks, >>>> >>>> Robert N M Watson >>>> Computer Laboratory >>>> University of Cambridge >>>> >>>> >>>>> Regards, >>>>> Javier >>>>> >>>>> uname -a >>>>> FreeBSD odin.valhala 7.0-BETA3 FreeBSD 7.0-BETA3 #0: Mon Nov 19 15:40:35 >>>>> ART 2007 >>>>> >>>>> Fatal trap 12: page fault while in kernel mode >>>>> fault virtual address = 0x18 >>>>> fault code = supervisor read, page not present >>>>> instruction pointer = 0x20:0xc07b8644 >>>>> stack pointer = 0x28:0xd6658a00 >>>>> frame pointer = 0x28:0xd6658a0c >>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>> = DPL 0, pres 1, def32 1, gran 1 >>>>> processor eflags = resume, IOPL = 0 >>>>> current process = 77347 (tcpdrop) >>>>> trap number = 12 >>>>> panic: page fault >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper(c0a5f1ea,d66588e0,c078878a,c0a5d5f4,c0b5bcc0,...) >>>>> at db_trace_self_wrapper+0x26 >>>>> kdb_backtrace(c0a5d5f4,c0b5bcc0,c0a1fb8c,d66588ec,d66588ec,...) at >>>>> kdb_backtrace+0x29 >>>>> panic(c0a1fb8c,c0a7c54d,c39ac220,1,1,...) at panic+0xaa >>>>> trap_fatal(c0a7c44f,c,246,c38c0210,c,...) at trap_fatal+0x303 >>>>> trap(d66589c0) at trap+0x10d >>>>> calltrap() at calltrap+0x6 >>>>> --- trap 0xc, eip = 0xc07b8644, esp = 0xd6658a00, ebp = 0xd6658a0c --- >>>>> turnstile_broadcast(0,0,c4c351f8,0,d6658b54,...) at >>>>> turnstile_broadcast+0x34 >>>>> _mtx_unlock_sleep(c4c35288,0,0,0,e103,...) at _mtx_unlock_sleep+0x52 >>>>> sysctl_drop(c0b0d2e0,0,0,d6658ba4,d6658ba4,...) at sysctl_drop+0x207 >>>>> sysctl_root(d6658ba4,100,1,c0937524,c1fbb1e0,...) at sysctl_root+0x127 >>>>> userland_sysctl(c38c0210,d6658c14,4,0,0,...) at userland_sysctl+0x134 >>>>> __sysctl(c38c0210,d6658cfc,18,c38c0210,d6658d2c,...) at __sysctl+0xdd >>>>> syscall(d6658d38) at syscall+0x335 >>>>> Xint0x80_syscall() at Xint0x80_syscall+0x20 >>>>> --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28148a3b, esp = >>>>> 0xbfbfe32c, ebp = 0xbfbfe358 --- >>>>> Uptime: 2d20h23m41s >>>>> Physical memory: 495 MB >>>>> Dumping 129 MB: 114 98 82 66 50 34 18 2 >>>>> >>>>> #0 doadump () at pcpu.h:195 >>>>> 195 pcpu.h: No such file or directory. >>>>> in pcpu.h >>>>> (kgdb) >>>>> >>>>> _______________________________________________ >>>>> freebsd-current_at_freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to >>>>> "freebsd-current-unsubscribe_at_freebsd.org" >>>>> >>> >>> > >Received on Sat Nov 24 2007 - 20:19:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:23 UTC