From owner-freebsd-current@FreeBSD.ORG Fri Jun 25 14:28:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6127416A4CE; Fri, 25 Jun 2004 14:28:39 +0000 (GMT) Received: from lakermmtao03.cox.net (lakermmtao03.cox.net [68.230.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id D065743D2D; Fri, 25 Jun 2004 14:28:38 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.localnet.net ([68.11.71.51]) by lakermmtao03.cox.net ESMTP <20040625142806.FSVS3786.lakermmtao03.cox.net@dolphin.localnet.net>; Fri, 25 Jun 2004 10:28:06 -0400 Received: from dolphin.localnet.net (localhost.localnet.net [127.0.0.1]) i5PES5mw083388; Fri, 25 Jun 2004 09:28:05 -0500 (CDT) (envelope-from conrads@dolphin.localnet.net) Received: (from conrads@localhost) by dolphin.localnet.net (8.12.11/8.12.11/Submit) id i5PES50X083383; Fri, 25 Jun 2004 09:28:05 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 25 Jun 2004 09:28:05 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Robert Watson cc: freebsd-current@freebsd.org Subject: Re: fetch hangs on 6/24/04 current build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 14:28:39 -0000 On 25-Jun-2004 Robert Watson wrote: > > It might be interesting to look at the following: > > - Use sockstat/netstat to identify the fetch socket, and see whether > either the send of the receive queue contains some amount of > persistent, un-processed data. This would suggest if the > application was stalling and not reading, or that TCP was stalling > and not sending. > > - Use DDB to generate a stack trace of the fetch process in-kernel, > perhaps a few to see whether it's stuck in one place, and if so, > where. This would tell us what it's stuck doing. > > - Use ktrace to generate a trace of fetch and "see what it's doing" > when it appears to hang -- is it looping waiting for I/O, just > blocked in kernel, etc. Good suggestions all. Thanks, I'll try those. Incidentally, it does seem to be working better this morning. Perhaps it *was* just an ISP glitch. -- Conrad J. Sabatier -- "In Unix veritas"