Bug #1179

panic: tcp_setpersist: retransmit pending

Added by rumcic over 5 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

History

#1 Updated by sepherosa over 5 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

#2 Updated by rumcic over 5 years ago

Uploaded the core dump to leaf:~rumko/crash/{kernel,vmcore}.0

#4 Updated by dillon over 5 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
<>

#5 Updated by sepherosa over 5 years ago

On Tue, Dec 16, 2008 at 1:07 AM, Matthew Dillon
<> 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 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?

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

#6 Updated by sepherosa over 5 years ago

Committed:
a48c5dd526
2d42d2b0d6

Also available in: Atom PDF