From owner-freebsd-net Mon Feb 21 4:47:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 7121137BBCB; Mon, 21 Feb 2000 04:47:30 -0800 (PST) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id NAA93976; Mon, 21 Feb 2000 13:47:24 +0100 (CET) (envelope-from asmodai) Date: Mon, 21 Feb 2000 13:47:24 +0100 From: Jeroen Ruigrok van der Werven To: Yoshinobu Inoue Cc: sameh@fr.clara.net, freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Panic (TCP) Message-ID: <20000221134724.J84100@lucifer.bart.nl> References: <20000221121246.F18727@noc.fr.clara.net> <20000221204008M.shin@nd.net.fujitsu.co.jp> <20000221125010.H84100@lucifer.bart.nl> <20000221212656L.shin@nd.net.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000221212656L.shin@nd.net.fujitsu.co.jp>; from shin@nd.net.fujitsu.co.jp on Mon, Feb 21, 2000 at 09:26:56PM +0900 Organisation: bART Internet Services B.V. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000221 13:30], Yoshinobu Inoue (shin@nd.net.fujitsu.co.jp) wrote: >> >Might there be incorrect memory over writing? >> >> How you mean? > >I think one possibility of the problem is that some code is >incorrectly overwriting some part of the memory, and a tcpcb's >tt_persist->c_flags is happen to overwritten. Hmmm, this box is a real disk io and network io bastard. It serves as a newspeer transit box based on diablo 1.27 with a fxp card and an amr array. Let me know if a dmesg is needed. >Now I am very much interested in the value of >tp->tt_persist->c_flags at panic, if CALLOUT_PENDING and >possibly other flags are just set, or completely broken data >is written on it. (kgdb) up 10 #10 0xc018abc4 in tcp_setpersist (tp=0xd5ce6b60) at ../../netinet/tcp_output.c:893 warning: Source file is more recent than executable. 893 (kgdb) print tp->tt_persist->c_flags $1 = 0 [I am upgrading the box to the latest sources as we speak, hence the sourcecode is newer] >And if later, I am also interested in other values around >tp->tt_persist->c_flags, to check what kind of value is >written around there. (kgdb) print tp->tt_persist $2 = (struct callout *) 0xd5ce6c44 (kgdb) print *(tp->tt_persist) $3 = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xcc401640}}, c_time = 22275044, c_arg = 0xd5ce6b60, c_func = 0, c_flags = 0} >> Debugging tips are welcome, since I am not the biggest bulb wrt >> debugging. > >I am not also, and you might have already known these things, >but in case they are useful, > > -If DDB is specified in kernel config file, and all src/sys > tree including sys/compile dir is saved onto another > machine, it will be very useful at next panic, because remote GDB > debugging is available by those data. I have a serial console active so I can do DDB from my workstation. Hence I always have a kernel and kernel.debug from the same sources. > (Though if the bug happens at very delicate timing, it > might prevent the bug from happening again.) > > -Adding some printfs in tcp_output.c:tcp_setpersist() panic > case might be useful. It might. -- Jeroen Ruigrok van der Werven Network- and systemadministrator bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message