From owner-freebsd-net@FreeBSD.ORG Sat Oct 14 00:45:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF57A16A403 for ; Sat, 14 Oct 2006 00:45:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B3C343D6D for ; Sat, 14 Oct 2006 00:45:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3BD9246D5F; Fri, 13 Oct 2006 20:45:50 -0400 (EDT) Date: Sat, 14 Oct 2006 01:45:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jonathan Feally In-Reply-To: <452FC336.6060504@netvulture.com> Message-ID: <20061014014441.D96390@fledge.watson.org> References: <452FC336.6060504@netvulture.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Problems with 6.2-PRE and udp applications - dhcpd and named X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2006 00:45:50 -0000 On Fri, 13 Oct 2006, Jonathan Feally wrote: > I have a P4 2.8 box running on an intel MB with a em0 acting as a firewall. > The em0 has multiple tagged vlans on it, no ip assigned to main interface. > Almost clockwork now, 6-7 days after bootup named or dhcpd completly locks > up. I can't even kill -9 the apps. I have recompiled both apps since > upgrading. I have only made two changes to this system around the same time. > 1. Removed 2nd em nic that had only 1 network connected not vlan tagged. 2. > Upgraded to 6.2-PRE > > Has anyone else had these problems? I am going to try running the system > with the internet connection not tagged to see if that helps. I've not seen this on any boxes. The usual debugging path here is to: (1) Look at the process wait channel in ps axl. (2) Compile KDB/DDB into the kernel, and do a kernel stack trace of the process. Once you know what the kernel thread associated with the process is doing, we can attempt to figure out why it's doing it. Robert N M Watson Computer Laboratory University of Cambridge