Date: Sun, 24 Dec 1995 15:46:50 +0000 From: mark@linus.demon.co.uk (Mark Valentine) To: KentH@HNS.St-Louis.Mo.US Cc: freebsd-current@FreeBSD.ORG Subject: Re: Kernel Panic in Current Message-ID: <199512241546.PAA01422@linus.demon.co.uk> In-Reply-To: Kent Hamilton's message of Dec 23, 11:39pm
next in thread | raw e-mail | index | archive | help
> From: Kent Hamilton <kenth@HNS.St-Louis.Mo.US> > Date: Sat 23 Dec, 1995 > Subject: Re: Kernel Panic in Current > > Garrett committed a fix for this recently - see sys/netinet/tcp_subr.c. > > > > * $Id: tcp_subr.c,v 1.25 1995/12/20 17:42:28 wollman Exp $ > > > > If you're up to date and still having problems, I can probably help you > > with a workaround... > > I'm current on it and I'm still getting the panic. I guess I'd like > to get some info about the work-around since I consult for the person > I'm connecting to and this is my way of getting in to do work. :-) OK, if Garrett's fix didn't solve your problem, my workarounds may or may not work for you too... Firstly, if you're using a small MTU (like 296), try using a larger one (I use pppd, and I just let it default instead of explicitly specifying 296 - you'll need to do whatever ijppp wants). This workaround was all I needed. If the other end is also trying to negotiate a small MTU, then I guess this might invalidate this workaround(?). Another thing to try is to lock the MTU associated with the route as soon as the link is up (the -lock and -mtu flags with route(8)). This might work because the bug seems to be to do with Path MTU discovery, which is disabled when the MTU is locked (if I follow that code correctly). My problem was the tcpcb t_maxseg going zero. You can check whether this is also happening to you in ddb by dumping the structure (the address is the first arg to tcp_timers in the traceback), e.g. "x/x 0xf083c900, 20" - decode by hand using sys/netinet/tcp_var.h. (If you can get a kernel dump and use kgdb, all the easier.) If nothing else works, then you'll have to hack on tcp_mtudisc() - see the code around ``mss = min(mss, offered);'' (there should be a comment there describing this problem). You can borrow some code from tcp_input.c:tcp_mss() - in particular, the line which falls back to tcp_mssdflt when the "offered" value is zero. Some printfs sprinkled around assignments to t_maxseg might also help figure out what's going on, if you have the inclination (in which case I can offer to forward you more details of my own debugging attempts). Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512241546.PAA01422>