Re: [PANIC] 7.0-CURRENT #0: Wed Mar 14 ...

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Thu, 29 Mar 2007 10:38:08 +0100 (BST)
On Thu, 29 Mar 2007, Wilkinson, Alex wrote:

> FreeBSD 7.0-CURRENT #0: Wed Mar 14
> I have no clue what casued this.
>
>    db> tr
>    Tracing pid 11068 tid 100224 td 0xc55dfa20
>    kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32
>    panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191
>    sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at
>    sbflush_internal
>    sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+
>    0x2d
>    sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int
>    ernal+0x15
>    sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c
>    soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247
>    soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37
>    fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814
>    5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f
>    7d95,d2,0) at fdrop_locked+0xe4
>    closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4
>    kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188
>    syscall(e8145d38) at syscall+0x155
>    Xint0x80_syscall() at Xint0x80_syscall+0x20
>    --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp =
>     0xbfbfebf8 ---
>    db>

There have a been a few such issues floating around, in which races between 
protocol teardown of a socket and socket layer teardown result in a panic 
during simultaneous access to the socket buffer.  Udate to at least 20070323, 
as glebius committed a fix for a class of these problems as 
uipc_socket.c:1.295 on 20070322.  If it recurs, please let us know.

Thanks,

Robert N M Watson
Computer Laboratory
University of Cambridge

>
>    db> panic
>    Startin
>    panic: from debugger.
>    M
>    cpuid = 10:36 obel
>    KDB: stack backtrace:/28 09:10:36, 0] prin
>    db_trace_self_wrapper(c0afcbb0,0,c09f95a1,187,c09f8dd0,...) at
>    db_trace_self_wra/etc/rc: WARNING
>    :cups_cache_reload(85)set properly - see rc.
>    Mar 28 09:10:36 ob
>    pper+0x37901]:   U
>    mi_switch(1,0,c09f8dd0,10e,e8145848,...) at mi_switch+0x3235)sedvmcore.2.gz
>    trap(e8145a74) at trap+0x2bc
>    calltrap() at calltrap+0x6
>    --- trap 0x3, eip = 0xc074c76b, esp = 0xe8145ab4, ebp = 0xe8145abc ---
>    kdb_enter(c09f8c53,1,c0a00d26,e8145af0,c55dfa20,...) at kdb_enter+0x32
>    panic(c0a00d26,c4f2da00,0,0,c5306bfc,...) at panic+0x191
>    sbflush_internal(c09f8814,4e4,c5306c68,c5306bac,c5306bfc,...) at sbflush_interna
>    l
>    sbflush_internal(c4ae8980,c5306cb8,0,ffffffff,7fffffff,...) at sbflush_internal+
>    0x2d
>    sbrelease_internal(c5306bfc,c5306bac,c0a00e0d,25f,c5306c20,...) at sbrelease_int
>    ernal+0x15
>    sofree(c5306bac,1,c0a00e0d,2bf,879) at sofree+0x19c
>    soclose(c5306bac,d2,0,c55c05a0,c55c05a0,...) at soclose+0x247
>    soo_close(c55c05a0,c55dfa20,c09f5288,879,c09f5288,...) at soo_close+0x37
>    fdrop_locked(c55c05a0,c55dfa20,2,c09fa79f,91,c55dfa20,e8145c08,246,c0b49cc0,e814
>    5c24,c0759807,c0b03834,0,c5585d2c,3f2,c09f5288,e8145c4c,c071e46e,c5585d2c,1,c09f
>    7d95,d2,0) at fdrop_locked+0xe4
>    closef(c55c05a0,c55dfa20,c09f5288,3f2,c55dfa20,...) at closef+0x1f4
>    kern_close(c55dfa20,c,4,c0a0f86b,1,...) at kern_close+0x188
>    syscall(e8145d38) at syscall+0x155
>    Xint0x80_syscall() at Xint0x80_syscall+0x20
>    --- syscall (6, FreeBSD ELF32, close), eip = 0x28298bbb, esp = 0xbfbfebec, ebp =
>     0xbfbfebf8 ---
>    db>
>
>    b> call doadump
>    Physical memory: 1003 MB
>    Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9
>    Dump complete
>    = 0xf
>    db>
>
>    db> reset
>    cpu_reset: Restarting BSP
>    cpu_reset_proxy: Stopped CPU 1
>
>    #sudo kgdb kernel.debug vmcore.4
>    Unread portion of the kernel message buffer:
>    panic: sbdrop
>    cpuid = 1
>    KDB: enter: panic
>    panic: from debugger
>    cpuid = 1
>    KDB: stack backtrace:
>    panic: from debugger
>    cpuid = 1
>    KDB: stack backtrace:
>    panic: from debugger
>    cpuid = 1
>    KDB: stack backtrace:
>    panic: from debugger
>    cpuid = 1
>    KDB: stack backtrace:
>    panic: from debugger
>    cpuid = 1
>    KDB: stack backtrace:
>    panic: from debugger
>    cpuid = 1
>    KDB: stack backtrace:
>    panic: from debugger
>    cpuid = 1
>    KDB: stack backtrace:
>    Physical memory: 1003 MB
>    Dumping 216 MB: 201 185 169 153 137 121 105 89 73 57 41 25 9
>
>    #0  doadump () at pcpu.h:172
>    172     pcpu.h: No such file or directory.
>            in pcpu.h
>    (kgdb)
>
> -aW
>
>
> IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.
>
>
> _______________________________________________
> 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 Thu Mar 29 2007 - 07:38:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:07 UTC