cvs commit: src/sys/bus/usb usb_ethersubr.c src/sys/kern kern_poll.c uipc_msg.c src/sys/net netisr.c netisr.h src/sys/net/ppp if_ppp.c src/sys/netgraph/netgraph ng_base.c src/sys/netinet if_ether.c ip_demux.c ip_input.c tcp_subr.c ...
YONETANI Tomokazu
qhwt+dragonfly-commits at les.ath.cx
Tue Apr 13 06:47:00 PDT 2004
Hi.
On Fri, Apr 09, 2004 at 03:34:10PM -0700, Jeffrey Hsu wrote:
> hsu 2004/04/09 15:34:10 PDT
>
> DragonFly src repository
>
> Modified files:
> sys/bus/usb usb_ethersubr.c
> sys/kern kern_poll.c uipc_msg.c
> sys/net netisr.c netisr.h
> sys/net/ppp if_ppp.c
> sys/netgraph/netgraph ng_base.c
> sys/netinet if_ether.c ip_demux.c ip_input.c
> tcp_subr.c
> sys/netinet6 ip6_input.c
> sys/netproto/atalk aarp.c ddp_input.c
> sys/netproto/atm atm_subr.c
> sys/netproto/ipx ipx_input.c
> sys/netproto/natm natm.c
> sys/netproto/ns ns_input.c
> Log:
> Push the lwkt_replymsg() up one level from netisr_service_loop() to
> the message handler so we can explicitly reply or not reply as appropriate.
>
> Revision Changes Path
> 1.8 +4 -0 src/sys/bus/usb/usb_ethersubr.c
> 1.9 +4 -2 src/sys/kern/kern_poll.c
> 1.6 +5 -6 src/sys/kern/uipc_msg.c
> 1.11 +2 -26 src/sys/net/netisr.c
> 1.12 +2 -2 src/sys/net/netisr.h
> 1.15 +4 -3 src/sys/net/ppp/if_ppp.c
> 1.11 +3 -1 src/sys/netgraph/netgraph/ng_base.c
> 1.11 +4 -0 src/sys/netinet/if_ether.c
> 1.16 +24 -0 src/sys/netinet/ip_demux.c
> 1.17 +7 -5 src/sys/netinet/ip_input.c
> 1.21 +2 -3 src/sys/netinet/tcp_subr.c
> 1.13 +21 -21 src/sys/netinet6/ip6_input.c
> 1.8 +3 -1 src/sys/netproto/atalk/aarp.c
> 1.7 +4 -2 src/sys/netproto/atalk/ddp_input.c
> 1.11 +1 -0 src/sys/netproto/atm/atm_subr.c
> 1.9 +8 -6 src/sys/netproto/ipx/ipx_input.c
> 1.15 +7 -2 src/sys/netproto/natm/natm.c
> 1.10 +9 -8 src/sys/netproto/ns/ns_input.c
After this commit(or maybe the next one saying ``Send connects
to the right processor''), mpd stopped working. Although
it doesn't panic, mpd gets stuck and become non-killable
process; ddb showed the following trace:
lwkt_switch(c5d75bc0)
lwkt_default_waitport(c5d75bd0, c8a56ac8, c7ec1ce0, c8a56b20, c01764a0)
lwkt_domsg(c021e4f0, c8a56ac8, 0, 0, c7ec1ce0)
so_pru_send(c7ec1ce0, 0, c5dbb100, c0f81a90, 0)
sosend
kern_sendmsg
sendto
syscall2
This is with the latest source(at least with after the removal of
TCP_DISTRIBUTED_TCBINFO). Does the recent changes require recompilation
of user-land applications?
By the way, is there a way to specify from which process to show the
trace in gdb -k? For example, mpd had pid 36 in the above trace, but
if I manually panic, savecore the dump and feed it to gdb -k, I don't
know how to specify the pid in gdb. It's too late to simply set a
breakpoint on lwkt_default_waitport after mpd got stuck because, but
if I set the breakpoint BEFORE mpd hangs, maybe I have to skip too
many false-positives before reaching the target.
More information about the Commits
mailing list