Bug 84952
| Summary: | "panic: sbappendstream 1" while using net/mpd | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Jimmy Olgeni <olgeni> |
| Component: | kern | Assignee: | Gleb Smirnoff <glebius> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 6.0-BETA2 | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->glebius Take it. On Mon, Aug 15, 2005 at 02:13:33PM +0000, Jimmy Olgeni wrote: J> While downloading data on a net/mpd GRE link, the following panic will occur Is this reproducible with debug.mpsafenet=0 ? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE On Mon, 15 Aug 2005, Gleb Smirnoff wrote:
> Is this reproducible with debug.mpsafenet=0 ?
I just checked with mpsafenet=0 and got this:
#0 doadump () at pcpu.h:165
#1 0xc0631ea8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397
#2 0xc06321bd in panic (fmt=0xc085d9c7 "sbappendstream 1")
at /usr/src/sys/kern/kern_shutdown.c:553
#3 0xc066e296 in sbappendstream_locked (sb=0xc22cf050, m=0xc223b100)
at /usr/src/sys/kern/uipc_socket2.c:741
#4 0xc06c737e in tcp_reass (tp=0xc229bc94, th=0xc2245048, tlenp=0xd58d3c04,
m=0xc223b100) at /usr/src/sys/netinet/tcp_input.c:372
#5 0xc06c9fb6 in tcp_input (m=0xc223b100, off0=20)
at /usr/src/sys/netinet/tcp_input.c:2350
#6 0xc06c1c91 in ip_input (m=0xc223b100)
at /usr/src/sys/netinet/ip_input.c:776
#7 0xc06a0cd6 in netisr_processqueue (ni=0xc096f7b8)
at /usr/src/sys/net/netisr.c:235
#8 0xc06a0e84 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:342
#9 0xc061f9b8 in ithread_loop (arg=0xc1e33480)
at /usr/src/sys/kern/kern_intr.c:545
#10 0xc061edec in fork_exit (callout=0xc061f89c <ithread_loop>,
arg=0xc1e33480, frame=0xd58d3d38) at /usr/src/sys/kern/kern_fork.c:789
#11 0xc07dc2dc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
--
jimmy
Jimmy, how often do you experience the panic? Can you please backout ng_ksocket.c to revision 1.53, and confirm/decline that your box is now more stable? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE Hi, On Tue, 23 Aug 2005, Gleb Smirnoff wrote: > how often do you experience the panic? Always, and immediately, as soon as the transfer starts. > Can you please backout ng_ksocket.c to revision 1.53, and confirm/decline > that your box is now more stable? With 1.53 it never crashed, running multiple transfers, even after a couple of hours. Looks fine! -- jimmy State Changed From-To: open->analyzed It seems that problem lives outside ng_ksocket, but the last change to ng_ksocket exposed it. It was backed out until I find the cause of the problem. Also note that PR kern/82413 is similar to this one. State Changed From-To: analyzed->patched Fixed in HEAD. You are encouranged to merge revision 1.57 of ng_ksocket.c into your kernel and report whether this fixes your problems. State Changed From-To: patched->closed Fixed in RELENG_[56]. |
While downloading data on a net/mpd GRE link, the following panic will occur: #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0631ea8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc06321bd in panic (fmt=0xc085d9c7 "sbappendstream 1") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc066e296 in sbappendstream_locked (sb=0xc27f2050, m=0xc222b600) at /usr/src/sys/kern/uipc_socket2.c:741 #4 0xc06c8880 in tcp_input (m=0xc222b600, off0=20) at /usr/src/sys/netinet/tcp_input.c:1280 #5 0xc06c1c91 in ip_input (m=0xc222b600) at /usr/src/sys/netinet/ip_input.c:776 #6 0xc06a0cd6 in netisr_processqueue (ni=0xc096f7b8) at /usr/src/sys/net/netisr.c:235 #7 0xc06a0eba in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:348 #8 0xc061f9b8 in ithread_loop (arg=0xc1e33480) at /usr/src/sys/kern/kern_intr.c:545 #9 0xc061edec in fork_exit (callout=0xc061f89c <ithread_loop>, arg=0xc1e33480, frame=0xd58d3d38) at /usr/src/sys/kern/kern_fork.c:789 #10 0xc07dc2dc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 A similar panic ("sbdrop") occurs on recent RELENG_5. Fix: Using ppp over tcp between the same hosts does not trigger the panic. How-To-Repeat: Running any verbose command over a ssh link ("find /") will panic the client side.