Bug #1179
closed
panic: tcp_setpersist: retransmit pending
0%
Description
With almost latest -HEAD (from about Dec 13 01:30:43 CET) I get the mentioned
panic. Panic message:
panic: tcp_setpersist: retransmit pending
mp_lock = 00000001; cpuid = 1
Trace beginning at frame 0xdca71cfc
panic(dca71d20,dd6e96a0,2,dd6e96a0,dca71d24) at panic+0x14d
panic(c0544cf8,dd6e96a0,dca71d34,c033d52e,dd6e96a0) at panic+0x14d
tcp_setpersist(dd6e96a0,1,dca71d50,c033d854,dd6e96a0) at tcp_setpersist+0x23
tcp_timer_persist_handler(dd6e96a0,dd6e987c,1,dd6e987c,0) at
tcp_timer_persist_handler+0x98
tcp_timer_handler(dd6e987c) at tcp_timer_handler+0xa4
netmsg_service(dd6e987c,0,1,ff8083b0,ff808000) at netmsg_service+0x79
tcpmsg_service_loop(0,0,0,0,0) at tcpmsg_service_loop+0x1d
lwkt_exit() at lwkt_exit
I'm in the process of uploading the cores, but the connection seems a bit slow
today so it will take quite a while.
I can't reproduce this panic, since it happened while I was sleeping (I know
rtorrent was running and I was updating applications from pkgsrc, but that
should have been it).
Also the backtrace:
(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc02852fd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc02855c0 in panic (fmt=0xc0544cf8 "tcp_setpersist: retransmit pending")
at /usr/src/sys/kern/kern_shutdown.c:800
#3 0xc033787b in tcp_setpersist (tp=0xdd6e96a0)
at /usr/src/sys/netinet/tcp_output.c:1039
#4 0xc033d52e in tcp_timer_persist_handler (tp=0xdd6e96a0)
at /usr/src/sys/netinet/tcp_timer.c:427
#5 0xc033d854 in tcp_timer_handler (nmsg=0xdd6e987c)
at /usr/src/sys/netinet/tcp_timer.c:667
#6 0xc0317043 in netmsg_service (msg=0xdd6e987c, mpsafe_mode=0, mplocked=1)
at /usr/src/sys/net/netisr.c:307
#7 0xc033a2cb in tcpmsg_service_loop (dummy=0x0)
at /usr/src/sys/netinet/tcp_subr.c:400
#8 0xc028c712 in lwkt_deschedule_self (td=Cannot access memory at address 0x8
) at /usr/src/sys/kern/lwkt_thread.c:228
P.S.: sorry about duplicate mails, post it to the wrong newsgroup by mistake
--
Regards,
Rumko
Updated by sepherosa almost 16 years ago
There is slight difference between current tcp timer and original code
(even with the priority message, I committed yesterday). The
difference lies within the callout_active() tests in !tcp_timer.c
files. I will work out the solution within next 2~3 days.
Best Regards,
sephe
Updated by rumcic almost 16 years ago
Uploaded the core dump to leaf:~rumko/crash/{kernel,vmcore}.0
Updated by sepherosa almost 16 years ago
Please test/review following patch:
http://leaf.dragonflybsd.org/~sephe/0001-Restore-the-semantic-of-callout_active-testing-on.patch
Best Regards,
sephe
Updated by dillon almost 16 years ago
:Please test/review following patch:
:http://leaf.dragonflybsd.org/~sephe/0001-Restore-the-semantic-of-callout_active-testing-on.patch
:
:Best Regards,
:sephe
:
:--
:Live Free or Die
It looks pretty good to me. I like the idea of just leaving the
message queued and not trying to dequeue it, but cleaning up the
tt_tasks bitmap.Is it possible to get rid of all those tp->tt_msg != NULL tests
by moving tt_tasks and tt_running_tasks out of the netmsg and
into the tcpcb proper?-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by sepherosa almost 16 years ago
On Tue, Dec 16, 2008 at 1:07 AM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
:Please test/review following patch:
:http://leaf.dragonflybsd.org/~sephe/0001-Restore-the-semantic-of-callout_active-testing-on.patch
:
:Best Regards,
:sephe
:
:--
:Live Free or DieIt looks pretty good to me. I like the idea of just leaving the
message queued and not trying to dequeue it, but cleaning up the
tt_tasks bitmap.Is it possible to get rid of all those tp->tt_msg != NULL tests
by moving tt_tasks and tt_running_tasks out of the netmsg and
into the tcpcb proper?
The callouts should not be used by listen TCP socket, whose tt_msg is
NULL (I cleared it intentionally). I think we could remove the
tp->tt_msg != NULL testing in tcp_callout_* functions; we probably
only need to test tp->tt_msg != NULL in tcp_close(). If it didn't
work out, I would put tt_tasks and tt_running_tasks into tcpcb.
Best Regards,
sephe