Date: Wed, 23 Feb 2000 00:32:50 +0900 From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp> To: wollman@khavrinen.lcs.mit.edu Cc: asmodai@bart.nl, freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Panic (TCP) Message-ID: <20000223003250I.shin@nd.net.fujitsu.co.jp> In-Reply-To: <200002221505.KAA07676@khavrinen.lcs.mit.edu> References: <20000221144858.O84100@lucifer.bart.nl> <20000222132327B.shin@nd.net.fujitsu.co.jp> <200002221505.KAA07676@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > If persist timer is working, and if it happen to timeout between > > callout_reset(tp->tt_rexmt, tp->t_rxtcur, > > tcp_timer_rexmt, tp); > > and > > callout_stop(tp->tt_persist); > > then the panic might happen at tcp_setpersist(). > > This should never happen, since this code is supposed to be running at > splnet(), which is supposed to block timeouts. Rather than papering > over the problem, I'd like to understand how it's possible. I also later thought so, but again I suspect that the part is also one of the cause of the problem. Because as the value of tp->t_rexmt at panic, retransmit timer also seemed to be running at the time, and I can't find any other place which might cause this situation. Also I think anyway the patch is better to be applied. My assumption might be wrong but I am now trying if I can create some patch that make the problem very likely to happen. Thanks, Yoshinobu Inoue > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > wollman@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000223003250I.shin>